Tell me if this sounds familiar. You have an idea for a product. You believe in it. Now you have to prove it.
So the months begin. You book meetings to get everyone aligned, and they are not aligned. You assemble market research from a dozen browser tabs and a couple of analyst PDFs, and it takes weeks, and some of it is stale by the time you are done. You write a requirements document. You rewrite it after the first review, and again after the second. You wait on a prototype, because engineering is heads down on this quarter's roadmap, and the version you finally click through lands a month later and is not quite what you asked for. You walk it through your stakeholders. They have notes. You go back around. Somewhere in there a competitor ships something close, or leadership moves the priorities, or the quarter simply runs out.
And then, if you are good and a little lucky, you arrive. You have a product the room agrees on. You have the buy-in. You have something a customer actually wants, with the evidence to prove it. That arrival is the entire job, and it usually takes a quarter to reach.
My team helps a customer get there in an afternoon.
I work on a team at AWS that helps education and government software companies turn ideas into products. A company brings us an idea. By the end of a single working session, about three hours, they have deep market research, a press release for the product written as if it had already launched, a full requirements document, and a clickable prototype they can put in front of stakeholders the next morning.
The speed is not the interesting part. Anyone can make an AI generate documents quickly. The interesting part is that the documents come out aligned, because the people who would know are in the room while they are written.
The working meeting
This is a working meeting, not a demo. We get the product team and their stakeholders together. Engineering, product, often marketing, and a leader who can say yes. It runs like a sprint planning meeting. The toolkit drafts each artifact in turn, and we stop after each one and review it as a group. The feedback goes back into that phase before we move to the next.
None of this is the AI being wrong and a human catching it. The toolkit does the mechanical work of drafting. The room does the part that needs judgment, in the order that lets the judgment land while it still matters. Maybe the model picked three competitors and missed the one that keeps them up at night. Someone says so, we add it, and the research updates. Maybe the press release frames the product a few degrees off from how the company thinks about it. We fix the language while the framing is fresh. Maybe a requirement is almost right and needs one clause changed. We change it.
I record the feedback as we go, so the corrections are captured and not lost to the meeting. Each phase carries the one before it forward, already corrected. By the last stage the prototype is built on requirements the team already argued about and agreed on.
It starts with research, not opinions
The first thing the toolkit does is research, and it does a lot of it. It runs six lines of inquiry at once. Industry, competition, customers, technology, innovation, and the policy and regulatory landscape. It reads widely across the web, far more than a person could in the time, and produces market sizing, a map of customer pain, and a technology landscape with the relevant AWS services marked on it.
This matters because most product conversations start from opinion. Someone is sure they know the market. Someone else is sure they know the customer. The meeting becomes a negotiation between confident memories. Starting from sourced research changes the argument. Now the disagreement is about evidence, which is a better argument to have. It is also the first place the room corrects the machine. The model's read of the competitive field is a draft. The people who live in that field make it real.
A press release before the product exists
Next the toolkit writes a PRFAQ. That is a press release for the product paired with a list of frequently asked questions, written as if the product had already shipped. It is an Amazon practice. The company spent two decades sharpening a method called Working Backwards, and writing the launch announcement first is the center of it.
It is a strange thing to do, and it works. Writing the press release forces a decision about what the product is, in plain language a customer would care about, before anyone has spent a dollar building it. If you cannot write the announcement clearly, you do not yet know what you are building. The toolkit drafts it from the research. The room reads it out loud and argues about whether it is true. That argument is the most valuable ten minutes of the day, and it happens before lunch instead of after launch.
Requirements that are testable
Then comes the requirements document. The toolkit writes it in a format called EARS, which is a way of stating each requirement so that it can be tested. Every requirement takes a When, the system, shall form. When a teacher submits an assignment, the system shall record the timestamp. It reads like a checklist a machine could grade, which is the point.
The document also names the people the product is for, the criteria for calling each piece of work done, and a diagram of how the thing is put together. The toolkit runs a pass it calls a Challenge Check before it writes any of this. The check stress-tests the assumptions in the press release, so the toolkit argues with its own earlier output before the room has to. The requirements are what engineering will build from, so this is where the room slows down and reads carefully.
A prototype that hunts its own bugs
Finally the toolkit builds a prototype. Not a slide of a prototype. A clickable set of web pages with working navigation, real-looking data, charts, and forms that respond when you use them. The team can open it in a browser and click through it the same afternoon.
The part I like best is the bug hunt. Before it hands over the prototype, the toolkit reads its own code, assumes there is a bug in it, and goes looking for proof. It treats its own work as guilty until checked. This is a small idea with a large payoff. The prototype you click through is one that already survived an adversarial read, instead of one that breaks the first time a stakeholder taps the wrong button in the demo.
The toolkit also has opinions about how the prototype looks. It bans purple gradients. I had to write that rule down explicitly, because left alone every model reaches for the same generic startup look, and a prototype that looks like every other AI demo undercuts the idea inside it.
The prototype is built to test an idea, not to ship one. It is real enough to click through and argue about, and it is not production code. That is the right amount of real. The job of the afternoon is to find out whether the idea is worth building, not to build it.
The discipline is the point, not the model
People assume the speed comes from the model. It does not. The model is a commodity, and a better one arrives every few months. The speed comes from the order and the gates. Research before press release. Press release before requirements. Requirements before prototype. A check at every seam that the phase is complete and consistent before the next one begins.
There is a lot of noise right now about AI work being slop. Slop is what you get when you skip the part where you decide what to build. The whole toolkit is built to make that part unskippable. It will not write requirements until the press release holds up, and it will not build until the requirements do. The discipline is the deliverable. The model just fills it in.
That is also why the meeting works. The structure hands the room a sequence of concrete things to react to, one at a time, in an order where each correction sets up the next. You are never staring at a blank page asking what we should do. You are reading a draft and saying what is wrong with it, which people are far better at.
It does have a failure mode. The toolkit does badly on an idea too vague to research. If you cannot say who the customer is, the first stage has nothing to pull on, and the meeting stalls there. That stall is useful. It tells you the idea is not ready, and it tells you in three hours instead of three months.
A toolkit, not a transcript
The whole thing is written as a set of plain-language procedures, not as code tuned to one model. Because of that it runs on three different AI coding tools. Kiro, which is AWS's own, plus Claude Code and Cursor. One set of instructions, with a thin adapter for each tool. When a better model comes out, it reads the same procedures and does the same jobs better. There is nothing to rewrite.
It is open source through AWS Samples, under the name Product Team's Tool Chest, so anyone can run the same sequence. We made it the standard on my team for a simple reason. What comes out the other end is what you need next. Artifacts good enough to take to your leadership for the budget, and a prototype real enough to put in front of customers to find out whether the idea is any good.
That is the part worth keeping even if you never open the toolkit. The speed was never the point, and neither was the model. What lasts is the sequence and the gates. Write the process down, put a check at every seam, and keep the people who know in the room. Do that, and whatever model you hand it to will build you the rest.
It is open source, so the easiest way to test that is to point it at an idea of your own and run it. Watch the artifacts come off the line, and judge the output it makes for you. That is a better test than anything I could tell you.