Most entrants in the innovation sprint stepped away from their day jobs for two weeks to build.
I got the same two weeks, but my day job didn't stop.
I built after hours and on weekends, and sometimes sent a few commands to my AI build team in between meetings.
I still shipped a full product.
I'm not saying that to boast. It backs up the previous piece in this series that with AI, engineering velocity is no longer the constraint in a product team. Deciding what to build is. Once I believed that enough to act on it, the question changed from "when will we have time to build this?" to "what should we build, and why?"
Product Forge was my answer to that question. It's an AI-first product management tool for PM teams who shouldn't need to live in a terminal to get the benefits of AI. Here's how it came together, what I learned building it, and why it never went anywhere.
Research first, build second
Before I built anything, I did what I'd always tell my team to do and rarely have time to do myself, research what good looks like.
I looked at tried and tested frameworks. I looked at what separated successful PM workflows from unsuccessful ones. I gathered brand and style guidelines. I defined the users specifically. What experience levels would be using this? What would they expect the outputs to look like? What would make them trust the tool enough to change their process?
That foundation took time. It also meant that when I started building, I wasn't inventing from scratch. I was implementing something with a clear shape.
What I built, and why
Product Forge is a WYSIWYG editor at its core. That was a practical decision. Most PMs don't work in markdown, and asking them to added friction to a process that was supposed to remove it.
If a tool needs a learning curve before it's useful, most people stop before they get there.
The product context setting came from a specific frustration. I was re-adding the same product background to every request, who the customers are, what the product does, what the constraints are. That's overhead. Product Forge lets you add context once and use it everywhere. Because different products have different contexts, it supports multiple products without them bleeding into each other.
One problem I kept seeing in practice was that we'd start with a clean idea, build momentum, and then hit complexity or technical constraints at the end, when changing course was expensive. Product Forge runs a solution architect feasibility assessment at the start of every flow, so the hard questions get asked before work begins.
Marketing is always the last team to know. They're handed a launch date and a feature list and asked to make it interesting. Product Forge brings them in earlier, with outputs they can use. The specification work gets done once and shared in a form that makes sense to them, as well as to engineering.
The same principle applies across the board. Functional specifications are full of information that's useful to sales, support and services, but they're written for developers. Product Forge adds side notes, callouts for each team flagging what's relevant to them. The spec stays the same, and each team can find their part of it.
The tool also generates Mermaid diagrams for process flows, screen specifications to support design and front-end development, and a persona creator and library that feeds into every downstream flow. Define your users once, and every later piece of work inherits that understanding.
How it came together
The MVP took a weekend. Then the iteration started.
I don't like this flow, move it around. Most people can't read markdown, build the WYSIWYG editor. I'm sick of adding product context to every request, add a context setting. We always hit complexity at the end, move the feasibility assessment to the start. Marketing is always left out, include them earlier. Specs are only useful to dev, add side notes for every team.
Every one of those changes came from using the tool in real work and noticing where it slowed me down, rather than from planning sessions or imagined user journeys.
Where I got it wrong
Every iteration surfaced another idea, and the pull to keep adding never stopped. I could add a roadmap visualiser. A stakeholder communication module. A risk assessment layer. The tool could do all of that.
For a while I kept stopping to ask whether each one would be useful, and whether it was worth the time and the tokens. Some ideas I dropped. But I never stopped thinking about the next one.
The previous piece in this series is about product teams building because they can, not because they should. I wrote it knowing the problem well. I still did exactly that while building a tool designed to prevent it.
Why it never went anywhere
The sprint ended with a demo session. We all presented our builds, and then they were judged. I didn't win, but I got a lot of comments and interest from other PM and design teams who watched on.
That was the moment to put it in their hands. I didn't, and Product Forge never got past the sprint.
Nothing broke and nobody shut it down. I was never happy with it. There was always a next idea, a better flow, one more thing that would make it ready. It never felt finished enough to put in front of people and let them use it.
The tool worked. It had the context setting, the feasibility assessment, the side notes and the persona library. Each of those solved a problem I had in real work. What it didn't have was a moment where I decided it was done.
That's the same trap from the other side. When building was slow, products stalled because there was no time to build them. When building is fast, they can stall because there's always something else you could build first. A weekend MVP is easy now. Deciding "this is enough, ship it and learn" is the part AI can't do for you.
There was another reason it never felt finished. AI and the tools around it change so fast that every week brought something new I felt I should fold in. A new model, a new way of working, a feature someone else had just launched. Keeping up with all of it is close to impossible, and trying to is its own trap. At some point you have to admit you can't keep up with every little thing, and get something out there to test and learn from.
Where it goes from here
I still see a lot of value in Product Forge. Since the sprint, I've worked through the MLP rebuild I wrote about in A Technical MVP Isn't a Product , and it taught me a lot about where Product Forge could be simpler and how it could be used better.
Three lessons would change it most.
Requirements have shifted. In an AI-native development lifecycle, requirements don't need to be as specific as they used to be. They need context, who the users are, what they're trying to do, and why. Personas carry more weight than a long list of acceptance criteria.
Journey flows are mandatory. The original Product Forge produced simple screen ideas for design. That's not enough. The journey flow needs more work and more investment than I gave it, because it's what keeps a fast build coherent from one screen to the next.
Context shouldn't live inside the tool. Since the sprint I've built a Context Repo. It lives in GitHub, Product owns it, and Design, Dev, QA and anyone else who needs product context uses it. It holds every user persona, with their journeys, pain points and background. It also holds deep domain knowledge about the product: how each section is used and by which persona, where things link together, and how changing one thing affects another section and another persona.
I'm now finishing a Knowledge Blueprint to add to it. It captures the context that has only ever lived in the heads of domain and product experts. All of it is in markdown files, so people and AI can both read it.
That flips one of Product Forge's core features. I built the context setting and persona library so you could define everything once inside the tool. The better design is for the Context Repo to feed Product Forge, so the same context serves every team and every tool, instead of sitting in one place only PMs use.
I'd tell any team I worked with to define done before they start, put the first version in front of real users, and let their feedback decide what comes next. I didn't do that for my own tool. When I pick it back up, and I will, that's where I'll start: a short list of what version one has to do, and a date to hand it over, whatever ideas are still on the list.
I just can't tell you when that will be. There's always a new idea and a new build competing for the time, which I recognise is the same pattern all over again.
