Chapter 8: Working with Product (or Being Product)

At startups with fewer than about twenty people, there is usually no product manager. The CTO and CEO together set the roadmap — the CTO through technical intuition about what is possible, the CEO through market intuition about what is needed. Marty Cagan, whose Silicon Valley Product Group has shaped how an entire generation thinks about product management, is explicit about this: "In an early stage startup, the product manager role is most appropriately played by the CEO or one of the founders."^[2]

This means the CTO is making product decisions constantly — what to build, what to defer, what to kill — while also being responsible for how it gets built. The dual role is a feature of the stage, not a personal failing. Karl Hughes, CTO of The Graide Network, describes the experience directly: "In my current role I lead both product and technology, which has been a stretch, but learning new things is the norm at startups."^[3] Lauren Mosenthal, CTO and Head of Product at Glassbreakers, found enough interest to start a peer roundtable for CTOs wearing both hats in the Bay Area — evidence that the experience is widespread enough to sustain a community but unnamed enough that nobody had organised one before.^[4]

Camille Fournier, former CTO of Rent the Runway, frames the underlying tension precisely: "The CTO must protect the technology team from becoming a pure execution arm for ideas without tending to its own needs and its own ideas."^[5] The CTO who wears the product hat is simultaneously the person generating the ideas and the person protecting the team from being overwhelmed by them. The tension is productive — it forces the CTO to evaluate every feature request against both desirability and feasibility in real time, with no handoff delay — but it is also exhausting. Peadar Coyle, a startup CTO who has written about the experience, is candid: "I’m personally skeptical of a CTO also wearing the head of product hat — it means that one person is juggling a lot of responsibility simultaneously."^[6]

The scepticism is warranted but misses the point. The CTO at a seed-stage startup is not choosing to wear the product hat. They are wearing it because there is no one else. The question is not whether to do the job. The question is how to do it well — and the answer, for technical founders, is not a specification document.

In the AI product community, "demo-driven development" has emerged as a recognised failure mode. The Applied LLMs collective — six practitioners with experience at Amazon, Hex, Weights & Biases, and GitHub — put it directly: "While the barrier to entry for building with AI has been lowered, creating products and systems that are effective — beyond a demo — remains deceptively difficult."^[7] Hamel Husain, who led the team that created CodeSearchNet (a precursor to GitHub Copilot), goes further: "Unsuccessful products almost always share a common root cause: a failure to create robust evaluation systems."^[8] The demo dazzles. The product disappoints. The gap between the two is where startups die.

And yet. At the early-stage startup, the demo is the most powerful product discovery tool the CTO has. The reason is a communication asymmetry that every technical founder recognises: explaining a technical plan to a non-technical CEO or customer produces glazed eyes and false agreement. The words are English but the concepts do not transfer. The CEO nods. The customer says "that sounds great." Neither has understood what was proposed, and the CTO has mistaken politeness for validation.

A quick proof-of-concept demo produces something different: real feedback. The CEO sees a rough prototype and says "that’s not what I meant" or "can it do this instead?" or "show that to the customer on Thursday." The customer sees a working prototype and uses it wrong — which is to say, they use it the way real users will use it, revealing assumptions the spec would never have surfaced. The product emerges from a conversation — demo, feedback, iteration, demo — rather than from a document that nobody reads the same way twice.

Teresa Torres, whose Continuous Discovery Habits has become the standard text on product discovery, describes the principle: "When brainstorming solutions, engineers often come up with the best solutions … because they have a depth of knowledge about what’s possible with technology."^[9] Her framework centres the "product trio" — product manager, designer, and tech lead — as co-equal participants in discovery. But at the seed-stage startup without a PM or a designer, the product trio is the CTO, the CEO, and the prototype. The demo is the discovery session.

The discipline is not in building the demo. Any engineer can build a demo. The discipline is in what happens after. A successful demo validates a possibility. It does not validate a product.^[10] The CTO who falls in love with the demo — who confuses the excitement in the room with evidence of market demand — is building on sand. The demo must be followed by the hard questions: Does this solve a real problem? Will users pay for it? Can we build it at production quality within our constraints? How do we measure whether it works? The demo starts the conversation. The conversation produces the roadmap. The roadmap produces the product.

This does not have to be the CTO’s demo. Some of the best features at any startup come from engineers who build something cool on a Friday afternoon and show it to the team on Monday morning. The room lights up. The CEO sees the business case. The whole company gets behind the effort to build it properly and ship it. The CTO’s role in these moments is not to be the innovator but to be the curator — recognising which demos deserve investment, ensuring that the path from prototype to production is staffed and scoped, and killing the ones that are impressive but strategically irrelevant. The key is to fail fast and try things out. The demo that dies after a day of work has cost almost nothing. The feature that survives six months of development without user validation has cost everything.

Husain’s warning about evaluation systems applies here with full force. The AI-powered product — and CorralData’s natural language-to-SQL copilot is precisely this kind of product — faces a unique version of the demo-to-production gap. The demo works because the prompt was crafted for the specific query the audience will see. Production fails because real users ask questions the prompt was never designed for. Marc Klingen, CEO of Langfuse, offers a principle that applies beyond AI: "Do not build workarounds for current model limitations" — invest in the problems specific to your use case, because the generic limitations will be solved by the next model release.^[11] The CTO building on foundation models must roadmap around a moving target: the capabilities of the product change every time the underlying model improves. Traditional roadmapping, with its fixed features and delivery dates, cannot accommodate this. Demo-driven development can, because the demo naturally incorporates the latest capabilities and the feedback loop is short enough to absorb capability jumps.

The Foundation Capital analysis of the AI startup risk is stark: "The model provider that powers you can also turn around and steamroll you."^[12] Model providers see which domains drive heavy API usage, which apps gain traction, and which features deliver results. The CTO building on third-party models must ensure that the product’s value lies in the system around the model — the domain knowledge, the user experience, the data pipeline, the evaluation framework — not in the model call itself. This is where demo-driven development meets architectural strategy: the demo reveals which parts of the product depend on the model and which parts depend on your team’s unique understanding of the problem.

The demo produces ideas. Ideas need structure. Structure means a roadmap. And here is where most startups go wrong.

Cagan frames the problem with characteristic precision: "Anytime you put a list of ideas on a document entitled 'roadmap,' no matter how many disclaimers you put on it, people across the company will interpret the items as a commitment."^[13] The sales team sells features from the roadmap to close deals. The board tracks roadmap delivery as a proxy for engineering productivity. The CEO references the roadmap in investor updates. The document that was supposed to communicate intent becomes a contract — and the CTO is the person held accountable when reality diverges from the plan.

Janna Bastow, co-founder of ProdPad and Mind the Product, invented the Now/Next/Later roadmap format in 2012 specifically to break this pattern. Her insight was structural: replace dates with time horizons. "The fundamental thing about the NNL is that it removes the constraints of the timeline and gives you something much more human: time horizons," Bastow wrote. "Time horizons are powerful because they allow you to move forward with a broad plan, yet only make commitments to what lies directly ahead of you."^[14] Now contains committed work with clear scope. Next contains validated problems with proposed solutions. Later contains strategic themes and open questions. The further out the horizon, the less specific the commitment.

Melissa Perri, whose Escaping the Build Trap gave a name to the pathology of shipping without learning, puts it simply: "A Roadmap is a communication tool first and foremost."^[15] The CTO who understands this distinction — communication tool, not delivery contract — can manage the CEO, the board, and the sales team without either overpromising or appearing evasive. The roadmap says "this is what we believe is most important, this is what we are learning, and this is where we think we are headed." It does not say "this feature will ship on this date."

The most common pathology is the sales-driven roadmap. John Cutler, who has written more about product management dysfunction than perhaps anyone alive, describes the dynamic: the sales team pressures the CTO to prioritise work to close a deal, the CTO complies, the roadmap becomes a collection of customer-specific feature requests, and the product loses coherence.^[16] Cutler documents the alternative through a salesperson he worked with who stopped selling the roadmap and started selling the team’s track record: "I sold our ability to innovate and I sold real ROI and outcomes, not future features."^[16] The CTO who enables that shift — by building a team that consistently delivers value rather than a roadmap that consistently promises features — has solved the sales-driven roadmap problem at its root.

Ross McNairn, CPEO at TravelPerk, provides the structural principle: "There is no distinction between technical and product roadmaps. If you refer to parts of the roadmap as 'engineering only', this creates a wall."^[17] The unified roadmap — where technical debt reduction sits alongside feature development, where platform investment is visible to the same audience that sees customer-facing work — prevents the CTO from having to maintain a shadow roadmap of "engineering work" that the business never sees and therefore never values.

Ryan Singer’s Shape Up, developed at Basecamp, takes the most radical position: no roadmap at all. Instead, Basecamp works in six-week cycles, with each cycle’s work shaped and committed at the start and nothing promised beyond the current cycle. Singer is candid about the limitation: "That 'no roadmap' style of working has a lot to do with the structure of Basecamp… they’re self-funded, profitable, and free from external pressures."^[18] For VC-backed startups with boards expecting quarterly plans, Shape Up’s purity is aspirational. But its core insight — that committing only to what you can see clearly and treating everything beyond the horizon as intent rather than promise — is the same insight that Bastow’s Now/Next/Later encodes.

The CTO who wears the product hat will eventually need to take it off. The trigger is not a calendar date or a headcount threshold, though both provide rough indicators. Jonathan Golden, who joined Airbnb as their first product manager when the company had 35 employees, provides the clearest diagnostic: "It’s time to hire your first product manager when all three of the following are met: You’ve achieved product-market fit and need to scale. Your engineering team is greater than seven people. You are mentally ready to let someone else control the roadmap at some level."^[19]

The third condition is the hardest. The CTO has been living inside the product — every feature decision, every trade-off, every customer conversation — and now must trust someone else with that context. First Round Review names the emotional reality: "Product is, understandably, one of the hardest LEGOs to hand to someone else."^[20] Nikhyl Singhal, who co-founded three startups before becoming Chief Product Officer at Credit Karma, calls the pre-PM phase a "drunken walk" — scrappy experiments, founder intuition, no process — and argues that the first PM’s job is not to replace that intuition but to structure it.^[21]

The CTO who hires a PM and then undermines their authority — reviewing every decision, overriding priorities, maintaining a shadow roadmap — has not hired a PM. They have hired an assistant. The transition requires the CTO to draw a clear boundary: the PM owns prioritisation and user outcomes; the CTO owns architecture, platform investment, and technical debt. Cagan is emphatic about the CTO’s retained domain: "Ultimately it’s the CTO’s job to ensure the systems and architecture can meet the needs of the business. Sometimes CTOs say that product won’t let them address it. But the CTO is wrong for even asking the head of product. This stuff is not up to the head of product."^[22]

The boundary also runs the other direction. The CTO who participates in product discovery — customer calls, prototype reviews, prioritisation debates — is doing their job. The CTO who dictates product decisions based on technical preference rather than user evidence is doing the PM’s job badly. Ebi Atawodi, Director of Product at Netflix, provides the principle from the PM’s side: "You are also 'product.' There’s no 'waiting for product' or 'product said this or that.' Understand that you’re a partner in this setup."^[23] The partnership model — where the PM, the designer, and the tech lead form Torres’s product trio, each contributing their domain expertise to shared decisions — is the target state. Getting there requires the CTO to let go of the what without letting go of the whether.

The Thoughtworks consulting team, writing on Martin Fowler’s blog, documents what happens when the transition fails: "At the beginning of a startup’s journey, aligning is natural because you are a small team working closely together. However, in the scaleups we work with, we find that product and technical teams are quite separated."^[24] The separation that Thoughtworks describes — "us vs them," with product throwing requirements over the wall and engineering treated as a feature factory — is the pathology that Cagan has spent decades fighting. His distinction between "empowered product teams" and "feature teams" is the diagnostic: in a feature team, the person who requested the feature — not the team building it — is responsible for whether it delivers value.^[25] The CTO’s job is to ensure their teams are empowered, not enslaved.

The CTO who hands off product ownership to a PM faces a temptation: retreat to the engineering side and stop thinking about users. This is a mistake. Cagan is direct: "If you’re just using your engineers to code, you’re only getting about half their value."^[26] The principle applies to the CTO as much as to the team. The CTO who stops attending customer calls, stops reviewing user research, stops participating in prioritisation — the CTO who becomes a pure delivery leader — has ceded the strategic function that makes the role executive rather than managerial.

Torres’s framework embeds this structurally. In the product trio model, the tech lead is responsible for feasibility — but feasibility is not a gate check at the end of the process. It is a creative input throughout. "We want them as active participants in the ideation process, not just recipients or judges of the outputs of that process," Torres writes.^[9] The CTO who participates in discovery can identify technical opportunities that no PM would see — an architectural change that enables a new class of features, a data pipeline that opens a market segment, a model improvement that makes a previously impossible product viable. The CTO who abdicates discovery loses this advantage.

Melissa Perri gives the pathology a name: the build trap. "There is a serious flaw with 'Move Fast and Break Things,' and it’s that most companies see this as an excuse to stop analyzing what they intend to build and why they should build it."^[27] The company in the build trap measures success by output — features shipped, tickets closed, velocity maintained — rather than by outcomes: revenue generated, users retained, problems solved. The CTO is the person best positioned to break the trap, because the CTO controls the team’s capacity and can redirect effort from building the wrong thing faster to discovering the right thing to build.

Cagan addresses the CTO directly: "In this case, my discussion moves to the CTO/VP Engineering, and I explain that they have mercenaries and not missionaries, and why they need to raise their bar on hiring engineers. At a minimum, they need at least one true tech lead on each product team, and discovery is one of the big responsibilities of the tech lead."^[26] The CTO who builds a team of missionaries — engineers who care about the problem, not just the code — has built a team that can participate in discovery without being asked. The CTO who builds a team of mercenaries — engineers who execute specifications without questioning them — has built a feature factory, regardless of what the org chart says.

The CTO’s relationship to product evolves through three phases that map roughly to the book’s four-stage model. In Stage 1, you are product — the demo is the discovery, the prototype is the plan, and the roadmap is whatever you and the CEO agreed on over coffee. In Stage 2, you are building toward product — hiring the first PM, drawing boundaries, learning to let go of the what while retaining the whether. In Stage 3 and beyond, you are a partner to product — participating in discovery, protecting engineering’s strategic investment, and ensuring that the team builds missionaries, not mercenaries.

The transition between these phases is one more version of the grief that Chapter 13 will describe: the loss of a role that felt natural, replaced by a role that feels bureaucratic. The CTO who was product — who knew every user by name, who could sketch the entire system on a whiteboard, who made prioritisation decisions based on a mixture of data and instinct that no PM could replicate — must accept that the company’s success requires giving that away. The demo that started as a conversation between the CTO and the CEO becomes a conversation between a product team and their users. The CTO’s job is to build the team that can have that conversation without them.