Takehome Studio: Building a Product-Judgment Workspace, Not an Answer Generator

Takehome Studio starts with the assignment and helps structure the discovery work around it. It identifies what is explicit in the source, proposes interpretations and evaluation signals, surfaces questions and stakeholder hypotheses, and helps the user build a working product frame.

But the stopping boundary matters as much as the functionality.

The product is designed to help organize ambiguity before solutioning. It does not decide the thesis, choose the solution, prioritize the roadmap, define the final MVP, or write the final recommendation on the PM’s behalf.

That boundary forced a series of product decisions.

Generated content could not quietly become accepted content. Inferences needed to remain distinguishable from source facts. Suggestions needed to be editable and removable. Reviewed material could carry forward; rejected material could not. The interface had to make those distinctions visible instead of hiding them behind a polished output.

The point of the review step is not ceremonial approval. It is where the user can correct the machine’s framing before that framing influences the next stage.

That became especially important in Product Framing. Gemini can review an existing frame and suggest alternatives, gaps, or wording improvements, but the current frame remains authoritative until the user chooses otherwise.

The important boundary was not whether AI could suggest a better formulation. It was whether a suggestion could quietly become the product decision. I designed the review step so that it could not.

At the end of discovery, the product consolidates the reviewed interpretation, signals, questions, stakeholder hypotheses, and product framing into a structured working summary. That summary is a checkpoint for the next stage of thinking, not a finished take-home answer.

I also experimented with Gamma as an optional way to package that reviewed checkpoint into a more polished artifact. Gamma was not doing the research and it was not meant to produce the final hiring-team answer. It was simply another way to carry an already-reviewed discovery state forward.

The more interesting learning came from building the product.

At first, working with Lovable felt close to describing a product change and watching the implementation appear. That is powerful, but it also makes it easy to mistake generated momentum for accepted product behavior.

I got better results when I became much more explicit about the change boundary.

Planning Mode became useful before larger changes. I started stating what had to remain unchanged, not only what I wanted added. I narrowed implementation requests, separated non-goals, and checked accepted behavior before moving on. When an issue crossed from interface work into repository or runtime behavior, Codex was often the more appropriate tool.

Over time, the prompts became less like requests and more like compact implementation contracts.

One concept I kept returning to was an AI Canon: a persistent record of product decisions, constraints, accepted behavior, and boundaries that should survive individual AI interactions. The practical problem is simple. A generated implementation can be locally convincing while still violating a decision made three conversations earlier. If the important constraints live only in conversational context, drift is predictable.

So the operating model increasingly became: make the decision explicit, preserve it, make a bounded change, inspect the result, and only then accept the new state.

That is not unique to AI-assisted implementation. It is recognizable product and delivery discipline. AI simply makes the feedback loop much faster—and therefore makes weak boundaries visible sooner.

A few days into the project, I learned about OpenAI Build Week.

It did not create the idea. I would have continued building Takehome Studio anyway. What it changed was the clock.

Build Week introduced a fixed deadline, submission requirements, and an external judging context. Suddenly the backlog had to become much more explicit. Ideas that were interesting but not necessary for the submitted product moved out of the MVP. Decisions that could otherwise have remained open for another few days had to close.

That pressure was useful because it reinforced something I already knew as a PM: focus is not a consequence of having fewer ideas. It is the discipline of deciding which good ideas do not belong in the product yet.

I tracked the work through delivery waves, gates, risks, validation, and explicit ownership across the tools I was using.

The dashboard is intentionally more operational than the product screenshots. It reflects the second half of the experiment: not just whether I could build the product, but whether I could manage AI-assisted delivery without allowing speed to erase control.

Takehome Studio became a working product rather than a static concept.

The submitted version is intentionally frozen while the Build Week process remains unresolved, so I am not treating the current state as an excuse to keep changing the product underneath the submission.

There are also deliberate omissions. The current product does not need accounts or a database to prove the core workflow. Analytics are useful for observing the experience, but they are supporting infrastructure rather than the story. A long list of possible extensions exists; most are backlog, not evidence of a larger product.

What matters to me in this version is simpler: the product makes its authority model visible.

AI can inspect, infer, suggest, and help refine. The user can review, correct, reject, and add. The accepted state carries forward. The final product judgment remains outside the generator.

AI-assisted building brings a product manager much closer to a working product.

That changes the economics of exploration. It makes it easier to test an interaction, inspect a flow, challenge a product assumption, and turn an idea into something other people can actually use.

But the leverage still comes from deciding what to build, what to preserve, what to trust, and what not to do.

The same principle that shaped Takehome Studio ended up shaping how I built it: AI can expand the work surface dramatically, but accepted product behavior still needs explicit judgment.

I originated the product concept, defined the workflow and product boundaries, drove the iterative product decisions, and directed the AI-assisted implementation and validation across Lovable, Codex, and other tools.