The New Stack of AI Tools for Product Managers

Product and software development roles are changing with a realistic possibility of operating as smaller units. As a product manager, we can speed up the process from idea to tickets, synthesizing market signals and customer feedback, building a working prototype, and sharing specs ready for dev, all in the same week. An engineer can take their own ideas into production code in a few days. A designer can rapidly test different mockups, code it, and hand off a working version for production in a day. The stages and hand-offs we're used to aren't as necessary anymore.

Tools were built to own the stages and support specific roles. Research tools for discovery. Roadmap and project tools for prioritization. Docs for definition. Design tools for mockups. Trackers for delivery, and so on.

The truth is, you don't need as many. The stack we see forming is consolidated around three core workflow steps.

Discovery, prioritization, and definition are now one job

You sat through the calls, read the tickets with feedback, did some market research, scanned emails, messages, and docs for decisions made, and then synthesized what you thought should be built and why in your requirements. Then it went for budget approval. Then it was broken down into specifications. Then it went for technical review. All before a line of code was written.

It might have been weeks (or months in some cases) between hearing something you thought was worth building and writing the requirements and specs. You don't have that time anymore. Building got cheap, so building to learn got cheap, which means the opportunity to build to earn comes faster.

What each step looks like

Discovery: We're always in discovery. You're not going to avoid the need to just sit with customers. Sit in meetings. Hear from people. But you don't hand-transcribe, and you don't have to be in all of them. You don't need to read every message, transcript, or ticket. Any AI will synthesize all that for you. What you need is that context loaded in an environment that surfaces it, helps you brainstorm and make sense of it, and then quickly distill it into themes, initiatives, features, and enhancements you can prioritize.

Prioritization: As you discover things, you need those themes, initiatives, features, and enhancements available, with context, in a format and tool you can query, build business cases with, and continuously keep updated. Roadmaps were never a reliable source of truth...they were based on estimates and hopeful thoughts. We're moving so fast to beat disruption; the "roadmap" has to be dynamic, outline thematic priorities, and get real about what's coming in the next 4-6 weeks.

Product Definitions: Product requirements documents (PRDs) were never the point. They are meant to serve as the business case and ensure alignment to purpose. The document wasn't meant to be a thing you sought to master or spend all your time on. The document was the artifact; the why and the evidence behind it was what you mastered. To operate in the AI world, it must be a living definition, continually pressure-tested, and updated collaboratively as the product adapts.

The context must stop getting dropped between them

The most reliable information came through you. You held what the customer said in your head until the prioritization meeting, then held the outcome of that meeting in your head until you sat down to write. Every hand-off was a rewrite, and every rewrite dropped the evidence and kept the conclusion.

Now it's one motion. What came in from a call is still attached when you rank it, and what you ranked is still attached when you write the requirement. Six weeks later somebody asks why you built the thing, and the answer is still sitting on it.

Design, validation, and build are now one job

You wrote down what you wanted. Design drew it. Somebody tested the drawing on five people. Engineering read the spec and then built it based on their best interpretation. Every hand-off lost a little of what you actually meant, and you found out how much of it at the demo.

That whole sequence existed because building was expensive. You made a cheap version, checked it, and only then paid for the real one. The actual building isn't expensive anymore. An afternoon of prompting gets you working code people can click. That means that your validated design gets a whole lot closer to what can actually built, and therefore, this steps can get collapsed.

What each step looks like

Design: We’re headed in a direction where the mockup can quickly become the build. You describe what you want and get something that runs. That doesn't necessarily make you a designer or developer. It just means the conversation with your designer and developer starts from a working thing instead of a description. You all get to shape an object's purpose and map the user's journey faster.

Validation: Yes, you go faster in the above, but it makes this step easy to skip. A working prototype doesn’t mean it will improve the user experience or grow your revenue. You still have to put it in front of people who don't understand it the way you do. I was talking to a former colleague a while ago in pre-sales solution engineering. He and his product team partner on field testing prototypes. He builds one using the design system, gets validation on the idea and feedback on the design, then passes that to product and engineering now. This is the way.

Build: The prototype is what you use to build to learn, and from which you shift to build to earn. The closer the prototype is to how your software is actually built, the closer it is to production-ready once you have enough signal to proceed.

The prototype becomes the connecting factor

The prototype will become the team's core artifact. It is the best visual representation of intent and purpose. Now, what goes into the prototype, all the engineering context and learnings that define its purpose, is absolutely critical to making the prototype effective.

What is at risk is losing the forcing functions to check if what we are doing is the right thing. Each stage made someone stop and check the work before it moved on. Collapsing steps means the pressure is on you to ensure it remains aligned to intent and projected outcomes.

The information product managers hold must remain apparent and flow as context throughout the process, even as you go from PRD to prototype to building faster.

Launch, measurement, and iteration are now one job

In the past, you picked a target date. Everybody built toward it. It went out to all your users at once, and then you waited for weeks to find out whether it was working. You argued over the results, then put in a fix you hoped would be delivered in the next cycle.

Now, you have to iterate faster. Which means you have to release, measure impact, and share those learnings faster. You need the performance metrics across the lifecycle, from delivery metrics to costs to revenue to get the complete picture.

What each step looks like

Launch: A launch can be a dial and rolling thunder of new things. You expose the thing to a slice of users and then keep deciding how far to turn it, which takes most of the drama out of ship day and makes it more continuous.

Measurement: You can now ask a question in plain language and have the answer in the same sitting. What that number means and what you do with it are still your challenge.

Iteration: The loop is short enough that you can adapt the product faster than you can tell a real signal apart from a week of noise. The need is to surface the signals at the beginning of this cycle and pressure-test them against other insights, faster than before.

When releasing new features and capabilities continuously, continuous measurement of user impact, costs, and revenue has to feed back into ideation and prioritization steps. If not, you’ll lose the learnings and the details in the commotion.

The key is keeping the tabs on the delivery, the measurements, and the signals in the same context you use to decide what's next.

The consolidated AI tool stack for product managers

Here’s my take on a consolidated stack. These are not meant to be only-use-these recommendations. You've got preferences different than mine, I know. Think of these as solid examples that are illustrative of the shift we're in.

‍AI tools for discovery, prioritization, and product definition

AI tools for design, validation, and build

AI tools for launch, measurement, and iteration

How to pick AI tools for product managers

Cover each job with as few tools as you can, then ask what each one can actually reach. Every seam between two of them is a place you retype the same context, and that retyping is the work you were trying to get rid of.

The tools that survive this see across a whole job. Anything built for one phase of a sequence that runs differently now will keep costing you a hand-off. None of which is a knock on the tools. They're good at what they were drawn against. The sequence moved underneath them.

Fix the decision gap

The gap is still in using the tools to make good decisions.

"Delivery of designs and code got very fast. Delivery of good decisions became the new bottleneck", said the respondent of the Product Circle research. 87.7% use AI coding assistants and 85.4% use AI for product work. But only 17.5% name strategic planning and roadmapping as an area where it made a real difference, against 50.2% for engineering and 45.3% for design. The job carrying the most tools got the least out of AI.

Where Product Studio fits in the product management process

Allstacks Product Studio holds your context throughout your lifecycle, so it helps pressure-test your ideas from discovery to validation, write great PRDs and specs, and measure the impacts through delivery.

It helps you gather and make sense of the signals to create a product definition grounded in reality. Helps you create the artifacts necessary to code a prototype. Then, objective AI reviewers review the draft for business case, feasibility, security, architecture, and go-to-market before you build. Then the finished work syncs into Jira, Linear, Azure DevOps, GitHub, and GitLab as build-ready tickets.

It takes the struggles of building an AI operating system away, and best part: Product Studio is free to start.

Feel free to message me on LinkedIn with questions or if you disagree with my list :)