The 3-Legged Stool of Product Development
There are many ways to structure a product department: engineering first, design admins, product managers as God, or the ever-popular HiPPO department structure.
But history has shown us that the best products come from the 3-Legged Stool product department where design, engineering and product management are three equal legs holding up the stool.
Jobs won over an entire planet with stunning designs, technically complex and yet simple to use. — 10 Leadership Tips from Steve Jobs
A lot has been written about how to build successful product teams. And there’s a lot of bickering. The engineer-led companies believe that without good programming your best ideas will be a piece of crap that crash, stall and break the internet.
They’re not wrong.
Designers point out that if you don’t back up your design decisions with research and user goals, figure out how to remove the friction and make the experience engaging and delightful, no matter how good the programming, the product won’t attract, keep or drive users.
They’re completely right.
Product managers will point out that if engineers and designers don’t consider the business model, work with SMEs and collaborate with stakeholders and attract investment then the whole project won’t even get off the ground.
Yes, couldn’t agree more!
The value is in the tension between us
Yet…while each of these is right, none is more right than the other. No one or two of these can make a successful product if a third (PM, eng, design) is the short or missing leg.
The stool will fall.
Think you can fast-track your MVP by throwing something online without any research or design? Think again. (RIP Google Glass, 2013–2014)
Think a cool product that works great is all you need to launch a business and go public? Um, tried and failed. (RIP Jawbone Fitness Tracker, 2011)
Okay, then start with a business idea, get yourself a designer, and hire some kid in his garage to make it happen. I’m looking at you. (Kanoa Wireless Headphones (2015)
Business structure counts
What happened? These product teams were missing one or two legs of the stool, or one leg was much longer than the others. When the value of either business, design or engineering is diminished or elevated above the other two, that becomes the flaw that breaks the product.
Short leg: design
I’ve seen startups where the designer was the admin for the engineers. One or two “design-guys” madly scratching out wireframes and assets as fast as an engineer demanded them. Research and design reviews were far between or nonexistent and talking to users was considered a waste of time. These teams were convinced that Google Analytics would tell them all they needed to know.
When design is a support role — or worse, an afterthought — it leads to broken or useless features, bloated products and a 33-screen onboarding flow.
Short leg: engineering
I’ve seen waterfallish eCommerce companies where product managers run around with their hair on fire, demanding solutions now! now! now! Here both engineering and design & research are short legs.
Ill-thought-out solutions are tossed over the waterfall to the engineering team (in the building across the street) never to be seen again until after the feature has launched. This inevitably triggers a new fire to fix the damage from the last fire, with the same amount of thought put into the feature as the first time around.
Long leg: design
And I’ve seen companies where the ECD is God, and not a pixel nor a line space can diverge from the style guide and the eagle-eyed rigidity of the brand team — no matter that the guide is from the last century and created for print use.
None of these structures produced well designed well-engineered, profitable digital products. They all failed in different ways, and for different reasons: bad design, too many friction points, no business model, bad engineering, no user need, etc. None of the problems was the fault of design, engineering or product management. These were structural problems.
Why does a product fail? It’s rarely a lack of talent in the team. It’s almost always a structure that sets up one part of the team to fail.
Product Development by HiPPO
For those not up on their business lingo HiPPO = Highest Paid Person’s Opinion. It means that whoever is seen as the top dog will have an overweight influence on decisionmaking. Often the HiPPO is your client or a stakeholder who is not on the team. There’s plenty of advice about how to handle those HiPPOs.
But when the HiPPO is a team member things get trickier.
- When engineering is the HiPPO, they have the final decision about what will get built and what won’t, and business needs or user needs may not have anything to do with that decision.
- If PMs are the HiPPO it is business über alles. Often this results in more ads, more interstitials and screen takeovers, and less interest in whether they’re driving users to delete the app or click away from the website.
- And, god forbid design makes the highest salary because then nothing will ever launch. (Though when it does it will look beautiful!)
And what happens when you’ve got two HiPPOs? Two heads pull in different directions indefinitely.
Summary
Teamwork is hard, and building the structure of a team is even harder. If you get it wrong, it doesn’t just make life for teammates miserable, it heavily influences the results. To make good decisions about a product, teams need to evaluate data about users, costs and the feasibility to build. They also need to evaluate whether their hypotheses or features will meet business goals or KPIs.
This requires a team structure that allows all this data to be evaluated equally. If one team member or group doesn’t have an equal voice, then those data won’t be evaluated with as much weight as others. Another way to put this, if one group has more power than another they will make the decision based on their biases.
The tension must be equal between all three: what to build, how to build it and why to build it. Three legs that hold up the stool.
