.png)
4 days ago
1
As the founder & CEO of Keeper for over 6 years, I had the opportunity to implement and iterate on a theory I’ve had for a long time about how to streamline product development.
The theory goes like this …
The traditional product development team structure (the trinity) is a legacy of a bygone era where all engineers were computer nerds, all PMs had MBAs, and all designers went to art school.
That’s not the world we live in anymore.
Software is ubiquitous and building it has become much easier. We’re not coding in COBOL, everyone knows how a button should work, and you don’t need an MBA to understand basic SaaS principles like net revenue retention.
In this new world, it’s time to replace the trinity with "the duo” — a leaner, faster, more empowered team structure.
This is risky post. Many people will interpret this as “Paul doesn’t think design matters” or “Maybe this works at a startup, but it could never work at BigCo“. Perhaps. All I ask is that you hear me out.
We’ve been using the duo org structure at Keeper (a Series A, 20 FTE, tax filing software startup) for over 5 years.
The system has evolved quite a bit in that time, but over the past few years we’ve coalesced around the following responsibility split:
Other requirements:
Product starters must have good vision / strategy comms AND UX intuition. Yes, this makes hiring harder. The way we do it is that we hire PMs that spike in UX, but you could also hire product designers with a knack for PM.
Strong adherence to a design system (for us, Material) means the product starter doesn’t need a visual design skillset. Everything is just “drag-n-drop”.
Product developers need strong project management skills - including interfacing with x-functional functions like marketing and customer support at time of release.
Product starters must align feature success targets before the release (like this) so that the product developer can easily monitor & report on it post-release.
Leveling guides need to be aligned. The more senior a product developer, the better they must be at monitoring and project management. It’s not enough to just build increasingly complex software. Similarly, product starters grow in seniority by getting increasingly good at UX design, not just talking in meetings and writing strategy docs. Here’s are the ones Keeper used: product starter, product developer.
1:5 ratio of product starters to developers has worked for us. Bigger orgs will probably want a slightly higher ratio (more devs).
Nits are like bugs, but require a UX-oriented fix. For example, “this feature icon is confusing” is a ‘nit’. Product starters are responsible for resolving these because they’re the ones who designed the feature.
So how does the product development process actually work?
I like to use the relay race analogy.
To kick off the race, the product starter …
Creates a PRD-like Figma file. Here’s an example. The benefit over a traditional doc PRD is that it’s a single source-of-truth for strategy and design, and is more visual — it shows rather than tells viewers about the current state of the world and what an improvement might look like.
Gets alignment with leadership on vision / strategy. To do that, they need to be great upward communicators and to have strong product analytics & strategy sense.
Specs the feature using existing component library. If a new component is needed, they will need to work with a specialist (for us, it’s a freelance UI designer). Sound annoying? Good! Creating new components should be hard! Otherwise your product will quickly become a cesspool.
Gets x-functional alignment on the feature spec. All the usual suspects - leadership, engineering, legal / compliance, marketing, ops, support. Product starters need to be experts in pitching and driving alignment.
Passes the baton to the product developer(s). This is typically an hour-long meeting where the product developer has already pre-read all of the specs and comes prepared with a list of questions. After this meeting, it becomes the product developer’s project so they’re incentives to understand it forward and backward.
After the baton gets passed, the product developer(s) …
Breaks up the feature into sub-projects. For bigger features, this may involve assigning tasks to developers on other teams. A good engineering manager will have to provide air cover.
Sets milestones & deadlines. Engineering managers will need to "pressure test” the deadlines developers set for themselves. The more senior a product developer, the more effective they’ll be in predicting scope and setting realistic deadlines.
Communicates those milestones & deadlines to stakeholders. Stakeholders want to know what to expect and when. In the trinity, they often go to the product manager for this info, but in the duo they go to the developer.
Builds the feature. In the “duo” structure, the product developer will need to not just build the spec, but take ownership over edge cases and analytics. They’re not just “code monkeys” because their head is on the line for making sure the release is smooth and that x-functional partners are happy.
Shepherds pre-release QA. While the product developer isn’t responsible for doing all the QA themselves, they are responsible for organizing it. This generally takes the form of a bug bash or async QA process.
Launches the feature. This is much more than just deploying to prod. It involves announcing it to team, writing up internal documentation, and informing customer support / marketing / ops.
Does post-release monitoring. Not just error monitoring, but actual product analytics. How many people used the new feature in day 1? Are we hitting the metric targets that the product starter got alignment on prior to the handoff? What qualitative feedback are we hearing from customers?
Like in the game “telephone”, every handoff introduces risk.
In a trinity process, the PM has to work really hard to communicate the importance of each business priority to the designer. All the context built by the PM during the strategy alignment / prioritization phase then has to get transferred to the designer to make sure the UX reflects business priorities. Either you move fast and risk misalignments, or you move slow and add lots of gates. You can’t have both (unless everyone on the team is a superstar!).
While the trinity system typically has 3-4 handoffs, the duo team structure only requires one. That’s a big deal. It’s much easier to traverse the design triple-diamond when most of the needed context is in just one person’s head.
Anyone who’s worked in a trinity before knows the more cynical ways to refer to the three functions:
PM = note-taker
Designer = interface-to-Figma
Engineer = code monkey
While the duo won’t magically turn everyone into a high-agency non-cynical employee, it does make it easier to feel responsibility for the results of your work. By removing one person from the loop, fewer decisions are “out of your hands”.
For example, product developers are more likely to spot and try to fix some confusing copy when they know that they’ll have to answer Slack DMs from customer support reps about it after the release. Similarly, product starters can’t just be completely top-down and then blame their designer for not “getting” their vision.
It’s not that the trinity can’t work, it’s just that there are more moving pieces. All three people need to be skilled, low-ego, and high-agency. The duo structure simply aligns incentives and removes barrier to making that more likely.
There are a lot fewer candidates with the exact set of overlapping skills / experience needed to work in a “duo”. In practice, it means we hire generalist PMs and them teach them design, generalist designers and teach them PM, and generalist engineers and teach them project / stakeholder management. To assess their intuition, we rely heavily on hyper-realistic exercises in our interview process. Like this one. We also still use industry-standard titles when communicating externally, like “product manager” instead of “product planner”.
The benefit of having three core stakeholders instead of two is that there is more veto power to prevent true catastrophes. For example, a trinity is more likely to prevent an insanely difficult churn flow because a designer’s only responsibility is great user experience. Without a dedicated designer, it’s more likely that an enterprising product starter will try and sneak something through. This just means more managerial oversight may be required to keep folks aligned with actual business priorities.
If your business is on the bleeding edge of AI research, you probably just want to hire the best AI researchers and let them do their thing. It would be foolhardy to filter down to just the best AI researchers who are also great at project management and stakeholder communication. The same goes for very brand or design-led businesses where they can’t simply inherit existing design / brand systems but have to create their own. Early snapchat is an example - they pioneered the “slide up” reels mechanic which probably required a specialist.
I think the duo structure is a “when” not an “if”.
The trend away from specialists is as old as time — as industries mature, fewer specialists are needed. Remember SDETs? Me neither.
Responsibilities merge as tooling improves, workforces are trained up, and industry best-practices are established. I think Gen AI will accelerate this as well.
Anecdotally, I hear from a lot of BigCo product people and founder friends that the transition is already underway. Airbnb got rid of PMs, Block got rid of PRDs, and a lot fewer companies are treating PMs like scrum masters.
However, the transition itself is tricky. People have to be re-trained, decades-old expectations have to get overturned. It could take another decade, or it could take a few years. We’ll see.
In the meantime, I think it’s important for employees to begin re-training and becoming better versed in their adjascent functions. There’s nothing wrong with a designer who can help steer product strategy - that’s a good thing. Engineers who take ownership over the release are more valuable than those who just see their job as meeting product requirements. Not to mention it’s more fun!
