The product trio, not a feature factory

The test for whether you're a feature factory isn't how much you ship.

It's who was in the room when the problem got defined.

If engineering's first involvement is a finished specification, you're a factory. However modern the process looks around it.

Everything downstream of that moment is execution, and execution is the cheap part.

The trio is the alternative: product, design, and engineering, co-owning the problem from the start, as three people who can each say the thing is wrong.

Three owners, one problem

The division that works isn't a division of the work.

It's a division of the question each person is responsible for keeping on the table.

Product owns whether this problem is worth solving.

What's the evidence. Who has it. What changes if we fix it, and what else were we going to do instead.

Design owns whether the solution fits the human. Not how it looks.

Whether the workflow matches the one people actually have. Whether the model in the interface matches the model in the user's head. Whether the thing being proposed makes the rest of the product harder to understand.

Engineering owns what it costs and what it forecloses. Not just build time.

What this does to the data model. What it means for the systems around it. Which of the three proposed options is a week and which is a quarter.

All three are inputs to the same decision, at the same time.

The feasibility input especially has to arrive during framing rather than at the end. The most valuable thing an engineer says in product work is usually "that version is six weeks, and this other version gets you most of it in four days."

That sentence is worthless once the spec is signed off.

What breaks with a handoff chain

Watch the specific failures. They're recognisable, and they get misattributed.

The expensive version gets built.

Nobody offered a cheaper option, because the person who could see it wasn't there when the approach was chosen. Single largest cost of the handoff, and it's invisible, since you never see the four-day version you didn't build.

Requirements get reinterpreted in implementation.

An engineer hits an ambiguity at 4pm, makes a reasonable call, and it's wrong in a way nobody discovers for three weeks. Multiply by every ambiguity in every spec.

Specs don't fail because they're badly written. They fail because no document survives contact with the twelve decisions nobody anticipated.

And engineers stop caring about the why. The slow one.

If your input has been unwelcome for a year, you stop offering it, and you get very good at building exactly what was asked for.

Usually described as a motivation problem and treated with a talk about impact. It isn't. It's a rational response to a structure.

When there's no PM

Common under thirty people, and the trio still applies.

What changes is who wears the hat. Not whether the hat exists.

Usually a founder holds product, and that's fine for a while.

The failure isn't the founder owning it. It's the founder holding it in their head and dispensing conclusions. The hat is worn, the questions aren't visible to anyone else, and so nobody can challenge them.

Minimum viable version: whoever holds product writes down the problem, the evidence, and what they expect to change. One paragraph, before any work starts.

Design and engineering read it and are expected to argue.

That's it. A paragraph and a norm, and it does most of what a trio does.

Watch for the trio collapsing into one person with three titles. A founder who owns product, does the design, and makes the technical calls has a very fast decision loop and no error correction, and the errors compound quietly for about a year before they show up.

Hire the missing legs before the habits set. By the time you have five or six engineers, one of the next few hires should be design or product, for reasons covered in the first-ten-engineers lesson.

How it actually runs, week to week

The trio is a way of working rather than a meeting, but it does need some structure or it decays into the same handoff with friendlier language.

The three of them look at the current problem together, weekly, for about an hour. Not a status meeting. A working session about what we're learning and what we're doing next.

They talk to customers together, at least sometimes. An engineer who has watched three customers use the thing needs far less specification, and is much better at the ambiguity-at-4pm decisions.

Decisions get written down where the team can see them: what we decided, what we rejected, why. Ten lines. This is what lets everyone else make consistent calls without the trio being consulted, and it's what stops the trio becoming a bottleneck of its own.

And the trio's output is a problem plus a direction, not a specification. The team is expected to make choices inside that. If the trio is producing documents detailed enough that no judgment is required downstream, you've rebuilt the factory with three signatures on the spec instead of one.

The failure modes of the trio itself

Two, both common enough to plan for.

The trio becomes a committee, and nothing gets decided without all three, and one of them is always in another meeting. Fix it by naming who has the final call on each type of decision. Co-ownership of the question doesn't mean unanimity on every answer, and someone should be able to break a tie.

Or one leg dominates. Usually product, occasionally a strong-willed engineer. It reverts to a handoff with extra meetings, and the tell is that the other two have stopped disagreeing in the session. Silence from a leg of the trio is a problem, not consensus, and it's the leader's job to notice it and ask.