By Shea Lutton and Eric Harper

Last week, Eric Harper and I laid out how LLMs are accelerating our work as product managers. It is now possible for PMs to validate feature needs with more clarity and speed because LLMs can build actual working prototypes from their product requirement documents. Taking this extra step means PMs can go further to validate the potential of new features with their customers to qualify the sales potential before developer time is used. 

LLMs like ChatGPT make PMs directly more productive, reduce development team work by eliminating prototype tasks, generate validated feature backlogs, and deliver more clarity to developers on what needs to be built. A prototype is worth 1000 meetings. 

In this post, Eric and I will show screenshots of the tools we use and the steps we take in our process. We’ll lay out the tools, structures, and skills necessary for PMs to start using these new methods. In our example feature, we’ll show how Eric used this process to build an actual feature for his AI-powered legal billing business, Serva Tempus. It highlights how PMs can be more entrepreneurial and iterate faster to find product-market fit.

Diving in

What is the process we use, what are the tools we use for each step, and what skills are required?

Phase	Tools	Skills
1. Context Library	Git, RepoPrompt, text editors, Cursor	Writing business and technical prompts
2. Feature Planning	DrawCast, ChatGPT O3, Linear	Whiteboarding, organization, markdown review, ticket review
3. Code Execution / Iteration	Cursor, Codex, GitHub, RepoPrompt	Code reviews, git workflows, environment setup,
4. Hosting/Validation	AWS or local hosting	Web server execution, containers

This process starts with a prompt library. The context of your business should be shared (via git) across all PM and engineering teams so as prompts are refined, the whole firm works with the same background and themes. The prompt library should include materials from across your business, laying out what your core products do for customers, your business strategy, brand style guidelines, UX/UI principles, engineering principles, security principles, and customer roles and personas. See our sample library here. 

With the right background context established, then we plan out our feature prototype. We spend as much time planning what we’re going to build as we do working on actual code which avoids endless iteration loops. 

The initial prompt is created with RepoPrompt and includes a map of the files in the application, the contents of key files like the database schema and core routines, the architect role from our prompt library, and our instructions to the LLM. The file map and file contents give context on how the existing app works now, before we expand the new feature. Our architect role is focused on the process we want to follow, not on code or infrastructure: 

The architect role in Cursor:

In this initial step, we are trying to create a single markdown file that serves as the equivalent of a technical implementation plan. The output markdown includes sections for business goals, key benefits, scope and requirements, success criteria, deployment plan, and go-to-market details. All the elements of a classic requirements document. This markdown gets a thorough read-through and edit using our brains to make sure it’s correct. Don’t skimp on review time.

A portion of the planning markdown:

From a high-level markdown, we prompt ChatGPT with our architect role to develop Linear tickets for each major step in the process. Why create Linear (or Jira) tickets? It might feel like an outdated process which can be replaced by AI, but through trial and error we found that planning out each major step helps LLMs to deliver more accurate technical implementations. 

For PMs working with a larger team, having a ticket structure gives clarity to the project and allows for parallelization of work to human and AI agents. The first tickets should be the data model changes and for these changes that need to be atomic, like database schema changes, we do not parallelize tasks. 

There are quirks that take some experimentation to figure out. On this day it took a few asks before ChatGPT output a single markdown file for us (instead of small fragments) and we had to tweak the prompt by removing the references to the Linear ticket and specifying (repeatedly) that the output should be a single markdown block. 

It is helpful to add negative feedback to your prompt library during your revisions. For a separate project to develop a simple marketing website Eric instructed to not add a honeypot or a rails app framework. These negative prompts set your business context for how you work, specifically the things your company does not do, like using certain technologies, process steps, or concepts.

Planning Acceleration

In the remote-work era, whiteboards are not used as much as they used to be. Eric and I both feel that the ability to draw out concepts, UX/UI elements, lists and tasks, and data flows on a whiteboard is a powerful tool to organize our thinking. Since LLMs can work with diagrams and convert handwriting into text, Eric is developing DrawCastAI (coming soon) so a phone camera can take continuous snapshots of a whiteboard and integrate the images directly into your LLM workflows. We both keep a whiteboard by our desks to convert brainstorming into requirements and actions and keep us in flow-mode for longer periods. 

Diagrams accelerate planning work. To illustrate a three AZ layout for high availability infrastructure in AWS, I was able to draw the picture below and have it be turned into a CloudFormation template.

AWS “nested boxes” architecture diagram:

For this application example, I needed a highly-available AWS ECS Fargate environment in three availability zones, auto-scaling up and down as needed. From the initial diagram, I got the right basic structure, but the template was missing the many standards I expect in a secured AWS account. I incorporate the aws.md file from our prompt library to revise the CloudFormation by reducing the IPv4 CIDR blocks, adding encryption, and specifying private subnets. 

This process of iterating on the CFN templates took less than 15 minutes, from drawing the original whiteboard sketch to the revised template with our environment standards. Writing out your standard patterns with your enterprise architects and engineering managers allows all the templates to be consistent with your security and architecture principles.

Code Execution

“I’m sipping rocket fuel right now,” a friend tells me. “The folks on my team who aren’t embracing AI? It’s like they’re standing still.”

With a solid plan and specific Linear tickets, it’s time to start generating code using OpenAI’s Codex to iterate on the code base. The first Linear ticket becomes the prompt to create the database tables and column changes. The work to this point has created a strong plan and atomic steps for updating the data model, creating the specific data extraction features needed, creating the UI, and maintaining the right permissions. 

Initial data model execution prompt in Cursor

Like Kenton V’s recent article on creating an OAuth library, the code produced can be amazingly accurate. In this case, the first commit (reviewed, not vibed) led to a working set of changes to the data model. 

Max Mitchell wrote an interesting blog post that prompts should be considered part of your source code. Since models are adding new capabilities so quickly, it will likely be just as important to save the prompt that led to the feature as the feature code itself. Certainly for PMs creating prototypes, developers who eventually turn the feature into a hardened, reliable production release will appreciate the background from those prompts.

Costs

The costs for these tools add up for individuals, but for Eric and me they are clearly worth the money. We pay: 

ChatGPT Pro	Cursor	DrawCast	RepoPrompt	Claude	Total
$200/month	$20/month	TBD	$15/month	$20/month	~$255/month

If you’re a solo entrepreneur or product owner, think of this as time and money you’re not paying your outsourced development teams. It takes some practice and repetition to learn and get fast with, but the learning curve is not that steep. If you run a large team of product managers, tool costs can add up. The way to think about this is not the cost for PMs, but the savings in development effort. It keeps developers out of meetings and focused on core platform features. And it can give you the opportunity to upskill or refocus your team and to move faster with less development effort. 

Here is a great article breaking down the costs. If your company will not pay for these tools, you need to raise the alarm that your skills are being left behind (and that your company is NGMI). Or simply pay for them yourself to keep yourself relevant. This is the fastest moving wave I’ve seen in my tech career and the value is obvious to those who spend a few weeks learning some new tricks. 

Skills to Build

If you’re a non-technical PM, you can start to build your skills with tools like Lovable or Replit. They are not as custom, and in my experience Replit can be somewhat obstinate in revising elements in a prototype or interface, but it is nearly instantaneous, easy, and can give customers an impression of the feature you’re exploring. Your prompt library and context are still relevant and work with these tools too.

If you’re semi-technical, this is the time to focus on your tech skills. Getting technically deep is valuable and the opportunity to master git workflows, set up your own CI/CD pipelines, and produce your own prototypes will give you more influence. The more you can validate ideas and act as an entrepreneurial agent, the more success you will have.

By Shea Lutton and Eric Harper

For product managers, a prototype is an invaluable tool to validate that you’re solving customer needs and to communicate exactly how a feature should look and feel. But prototypes require a critical tradeoff, your development team has to sacrifice their current feature work in order to build the prototype, slowing down feature delivery. LLMs are eliminating this tradeoff by enabling PMs to build prototypes independently. 

ChatGPT allows product managers to go far beyond simply distilling customer needs into product requirement documents. In 2025, PMs can use the power of LLMs to test customer needs themselves by building working prototypes and directly testing feature value with customers.

In our experience, using these PM techniques on revenue generating features (but at a small scale) has made us 4x more effective than traditional PM workflows. It reduces our time to validate concepts with customers, boosts our personal productivity, avoids using developer time for prototyping, increases clarity (and avoids meetings!), and ultimately lets us focus development effort on features with proven value for our customers.

Forget product requirement documents, the future of product management is independently building feature prototypes for direct customer feedback. 

As early adopters, engineers have written about the many ways that LLMs make them more efficient. Less has been written about LLM impact on other roles such as product management. What is the state of the art in product management in the LLM era? Simply using ChatGPT to write emails, PRDs, or roadmap documents is a marginal gain, maybe 5% to 10% more effective week over week.

LLMs for PMs

LLMs are starting to show how useful they can be for non-engineering professions, and that will increase in the future as more people start to use these tools in different settings.

PMs can use LLMs to replicate the productivity of an entire team of PMs, UX/UI designers, engineering managers and software engineers by developing business and feature context for ChatGPT. Since the goal of a PM is to condense the most valuable customer needs into clarity for what needs to be built, building a model yourself helps you iterate faster to validate customer needs. It turns a long prototype cycle into much shorter feedback loops, moving from this workflow:

2024 Workflow:

To a shorter, independent feedback loop. Fundamentally, when PMs can work unaccompanied and get further into the development process, they can significantly accelerate the pace of feature discovery. PMs can talk to customers, build a hypothesis for what features drive the most value, independently build a prototype, and gain direct feedback on the value. That short cycle will be the way great PMs work by the end of 2025 (if they are not already!).

2025 Workflow:

The ability for PMs to validate prototypes in this way is a major step towards the teachings of the “Lean Startup” by Eric Ries or the “Startup Owner’s Manual” by Steve Blank. PMs can validate ideas and iterate without having to dedicate the critical cycles of a development team to test a new feature. 

In modern software development, the development team is the key constraint that limits your rate of progress. For readers of “The Goal” or “The Phoenix Project”, this is the key insight from both books. Having PMs identify if they are solving the correct issue means that development teams are focused on solving qualified customer problems.

Planning

We’ll show you the tools, methods, and structures we use in our modern PM workflows. But first, let’s take a second to reflect on what parts of the PM process are still valuable. 

Good planning is key for LLMs just as it is for humans. A one-shot prompt is as likely to deliver a valuable customer feature as 1000 monkeys are likely to write the next Principia. 

Our first take-away is that the PM process of aggregating many customer needs into a priority list, then creating feature briefs for the most compelling needs, and validating those features in a detailed product requirement document (PRD) is still a highly useful exercise. It’s the most effective way to confirm that you’re focused on the most important problems for your customers. Without this examination, organizations have a tendency to focus on easy problems, regardless of how valuable they are for your customers. Our workflow uses a standard template to help us deliver organized ideas in a one page format to test the concept. If that meets our requirements, we progress into a full plan using AI tools. 

All of your business, customer, and technical context is separate from feature requirements, but it’s important to the final product. We create a structured library of code prompts that allow us to load the context we need from various personas and perspectives to generate code for our business needs. This includes business context about your industry, strategy, product value, customer roles, and details of your tech stack (languages, frameworks, tenets). 

The same way a clean code repo breaks source code into logical structures, we break out prompt context into user roles (both internal and external stakeholders), brand style guidelines, go to market standards, and the principles and standards for how our companies build software. PM leaders should be intentionally developing these libraries across their teams to apply your principles and standards consistently across prototypes.

We split our prompt context into small chunks to balance the cost and speed of token processing against the quality of the results. We find we get better results by starting our prompts for code with business context and feature requirements from our planning work. We take the resulting code, add additional role context and iterate several times, such as loading the security architect role and revising the code for security quality. Even for limited prototypes, security is tremendously important and there is no substitute for engaging our brains for deep security reviews of the code produced. Working to balance token/context size may be a temporary limitation as ChatGPT rapidly advances, but in early 2025, adding context and doing multiple revision passes has given us the best results. 

Prototype Development

From this point, PMs can start using AI tools to directly code working mockups. Why have PMs do this and not pass the task off to a developer? Speed, accuracy, and money. The PM already has the context of the customer’s need in their head. LLMs use the context library to develop code for a working prototype, and the PMs can take those mockups directly to customers for feedback. Only when customers have reacted favorably to a feature mockup and given positive sales signals will you pass a prototype to the development team. 

In our workflows, this means PMs create new dev branches in git, paste Linear ticket information into Cursor along with relevant prompts from the prompt library such as the style guide (colors, fonts, and presentation), the design principles, the needs of various customer roles, and the internal development standards such as frameworks, languages, and architecture standards. The output of this work will be qualified customer feedback. 

If it’s valuable to customers, then it’s worth having your development team turn it into a real feature (with real security, real authentication, real redundancy, real SRE, and real business continuity). The ability for PMs to independently generate prototypes does not lessen the need to build secure and reliable products. You still need your engineering team. 

What to Watch For

What can go wrong building a prototype this way? When the output is wrong, it usually fits into one of these categories:

1. Tech incorrect – The code or solution does not work (needs iteration)
2. Tech correct, but missed the broader purpose – When your code works but it’s only solving part of a broader issue (revise planning)
3. Business incorrect – The result works but is not helpful to customers as expected (revise business context and replan)

As you catch these errors, add material to your prompt library to correct the misunderstanding and iterate. It’s also helpful to add negative prompts, such as a “Never Do” section that corrects initial coding mistakes. Also explicitly ask ChatGPT what questions it has and what assumptions were made. 

Changing Needs

In 2024, a great PM knew their user base, knew their product inside and out, and wrote clear documents for how the next feature should be delivered for customers. In 2025, using AI enabled tools, a great PM can go much further, replicating the productivity of a team of six to eight people by building prototypes themselves to confirm if features are valuable to customers.

Your team should start collaborating on a team-wide set of role prompts and business value prompts to start producing full working prototypes. PMs need to advance their skills to take advantage of the opportunity in front of them. 

In our next post we invite you to look at the suite of tools that Eric Harper and Shea Lutton use to accelerate product development such as DrawCast and RepoPrompt to boost your team’s productivity. If you would like us to come and speak with your team about how the AI era can boost your company’s productivity, please contact us. 

Recently I was asked to help investigate the performance of a fancy bit of hardware. The device in question was an xCelor XPM3, an ultra low-latency Layer 1 switch. Layer 1 switches are often used by trading firms to replicate data from one source out to many other sources. The exciting thing about these kinds of switches is that they can take network packets in one port and redirect them back out another port in 3 billionths of a second. That is fast. This may be no surprise, but that is so fast that it is pretty hard to measure.

To measure something in nanoseconds, billionths of a second, you need some equally exotic gear. I happened to have an FPGA based packet capture card with a clock disciplined by a high-end GPS receiver, some optical taps, and a pile of Twinax cables. Oh boy, let the fun begin. Even with toys like these, the minimum resolution of my packet capture system was 8 nanoseconds, nearly 3 times slower than the XPM3 can move packets. To get around this problem, I replicated each packet through every port on the XPM3, bouncing it all the way down the switch and back. Physically this meant that every port was diagonally connected with Twinax cables like this:

And inside the XPM3 it was moving data between ports like this:

The problem now is that I have two variables. Sending a packet down the switch this way means that it moves through 32 replication ports (r) and 30 Twinax cables (t). After running 10 million packets through this test setup, I knew that 32r + 30t + 35 = 212.93259 nanoseconds on average. The ‘35’ is the number of nanoseconds it took for the packet capture system to timestamp the arriving packets. But how could I determine the time for replication and the time in the Twinax cables? The answer was to get a second equation so that I could substitute variables.

I ran a second trial using just ports 1-8 instead of the full 32 ports. This gave me 8r + 6t + 35 = 75.958503 nanoseconds. Now with two variables and two equations I could simply substitute them to calculate that a replication port took 3.35 nanoseconds per hop and Twinax cables took 2.34 nanoseconds for each .5-meter length.

The Chicago based bike sharing company, Divvy, hosted a contest this past winter. They released anonymous ride data on over 750,000 rides taken in 2013. The contest had several categories to see who could draw the most meaning from these data and who could design the most beautiful representation of the rides. I entered the contest as a way to learn about D3.js, a new data visualization tool that is amazingly powerful. And complicated.

I thought it would be fun to see where most people were coming from and going to. When I start a play-project like this, I reach for my two favorite data analysis machetes, Postgres and Python. Cleaning and loading the data into Postgres was pretty straight forward, which lead to the fun part, trying to derive a meaningful framework with which to examine the ride data.

Pretty quickly it became apparent that breaking down the day into small time slices and aggregating the top departure points would yield interesting insights. It became even more interesting when you categorize the top departure points by their corresponding top destinations. 

At different times of the day the pattern of rides looks wildly different. Early in the morning a massive influx of riders use Divvy bikes near the citys two main train stations. In the middle of the day, bike usage centers around the primary tourist attractions with everyone coming and going to the same places. And in the small hours of the morning the bikes serve as cab replacements in the neighborhoods with lots of bars. 

With the ride data extracted, I used D3 to make it beautiful. D3 allows shapes to move and change color in seemingly magical ways inside a web browser. Each departure point can be linked to its top destinations and they will arrange themselves. Crain’s Chicago Business newspaper saw my entry and is running a special print edition of the graphic in an upcoming paper. You can see the online edition here.

In 2008 the property bubble burst in Chicago. It is hard to gauge a recession without some hard numbers. In this case a visual representation gives a powerful view into the scale of the decline in building activity, measured by the total value of building permits by large builders. The visual gives a reference for the scale of the recession. A big thank you to the Chicago’s Open Data Portal for providing the data to work with.

The Data Portal has all the Chicago building permits available online which are a great metric for building activity. I narrowed down the permits to construction activity (elevator repair and fire alarm systems didn’t count) and used Python and Gephi to graph out the connections. Take a look at the result:

It was important to filter out smaller builders to have a clear image. The threshold for a builder to make the graph was at least 100 building permits or total permit value of over two million dollars. Each year is scaled to the total value of the building permits for that year, ranging from $8.3 billion in 2006 down to $752 million in 2009 and back up to $4 billion in 2011. Look what happened to John C. Hanna’s activity. In 2006 Hanna’s firm was the most active by properties. In 2007 and 2008 the activity was significantly reduced and failed to make the graph in 2009. By 2010 Hanna was back on the graph and by 2011 was growing again.

If you would like the higher resolution version or a PDF of the image, contact me.