When I’m exploring a new idea, I’ve found that building small prototypes is the fastest way to test assumptions. Lately, I’ve been experimenting with running prototyping “sprints” in Cursor and it’s changed how quickly I can move from idea to outcome.

My role in these sprints is to maintain user goals and product outcomes, as much of my background is in product management and design. I let Cursor handle the development and technical feasibility side of the Team Lead Triforce. I use a lightweight product management approach on top of the coding agent, keeping it on the rails and steering it toward delivering user value.

Start with a Product Outline

Before I ask Cursor to generate any code, I create a foundation. It’s tempting to dive in and start prompting right away, but that usually leads to meandering results at best and non-functional ones at worst. Instead, I create two markdown files in a new directory (I usually name this /product-management):

• Product outline — who’s the user, what’s their goal, and what assumptions is the product making? What milestones do I want to achieve and validate with the prototype?
• Architecture + data model — What tools, services, or solutions could be used to support the prototype? What’s the simplest system or data shape that could support this idea?

I don’t spend hours polishing this. I usually have thoughts or previous notes I can use as a starting point, and once they’re there, I’ll use each document as context in Cursor to expand and refine. Keep in mind these are foundational concepts – I’ve often found I need to make corrections to the scope, direction, or explanations that the agent takes. Also, because they’re foundational concepts they shouldn’t change too much once you start prototyping, so keep an eye out for agent changes (or use a rule to prevent editing from the get-go).

Plan in Sprints

Once I have the outline, I shift into sprint planning. To begin, I prompt the agent to use the docs in /product-management to come up with a “product roadmap” that produces user value at each step. Again, I’ll iterate on this with the agent using both common sense and product gut-feel, and think about questions like “what are important areas to de-risk” or “what are the fuzzy areas that could use additional exploration”. I’ll put this information in something like product-roadmap.md

Once I’ve got a tentative roadmap, I’ll ask the agent to come up with a plan for Sprint 1 which usually focuses on installing packages it thinks it needs and getting a development environment up and running. I’ll give it a general structure to follow and ask it to split up the work into features, then stories, and then tasks to accomplish, which are all put in a separate markdown file named sprint-planning.md.

By getting to development tasks in this way, I’m essentially creating the agent’s “todo list” when I ask it to take a whack at developing a feature or story. This keeps it from wandering off into over-engineering or producing code that looks nice but misses the true intent of what needs to be accomplished. Similar to regular software development, it’s alright to have an idea of what might be coming in Sprint 2 and beyond, but don’t go through the effort of planning them out in detail. The scope will most likely change based on what you learn in each sprint!

Start building

At this point I have the agent start working through the sprint plan, with instructions to stop after each story and provide me with testing notes. I’ll validate that it’s actually accomplished the story’s goal and works correctly before instructing it to move on to the next story.

Sometimes it works. More often, it half-works. That’s fine — I treat it like QA”

• Run the code
• Test: Spot where it fails, where it misses the mark, or what needs to change
• Triage what needs to change -> errors and notable bugs are immediate fixes, but additional product changes or enhancements can go into the backlog
• Wash, rinse, repeat until the story is done
• Then move onto the next story

Using this framework, I usually find a “sprint” will take me between 1 to 3 hours, depending on complexity.

Refine as You Learn

Prototypes aren’t just about making an interface or a feature, they’re about learning and testing assumptions. Every new “sprint” brings new insights: a data model that doesn’t quite hold up, a user flow that feels clunky, or a feature that turns out to be unnecessary.

I take those learnings and prompt the agent to create a sprint summary (placed in the sprint planning doc) and incorporate them into the next sprint’s plan. This way, the context for each new sprint is informed by the last. Over time, the prototype sharpens. What started as a vague “what if?” becomes a working system I can demo, test with others, or decide to set aside.

Keep It Simple

One thing I’ve learned: don’t over-document. This is similar to getting lost in documentation across many different files in a normal development workflow. The point of this process is to keep context for the agent (and myself) manageable. The long-running sprint planning doc is the “working brain”, while the product outline, architecture, and roadmap serve as my “evergreen content”. As needed, I’ll incorporate insights from sprints back into that stable documentation when a foundational assumption changes.

Closing Thought

Working with Cursor this way has helped me combine the speed of AI-assisted coding with the guardrails of product management. By using the same iterative/Agile approach with prototypes as I do with development teams, I’m able to explore ideas quickly and efficiently.