One thing I have tried to make sure wherever I have run direct to consumer Product is to that the goal of the product + engineering teams is solving business problems, as opposed to knocking items off a roadmap list, however efficiently.
Knocking items off a list is akin to treating the symptoms rather than the underlying problem. Typically, the business owner doesn’t see enough users or enough revenue on their top-level dashboard (the symptom), so they keep suggesting product improvements and enhancements hoping one of them will be a hit with customers.
This is instead of tackling potential underlying problems. Poor free trial conversion rates, poor repeat usage of a particular revenue generating feature, below-par referral rates from existing customers, frequent customer complaints about a common issue – these are what problems sound like.
Marty Kagan of the Silicon Valley Product Group contrasts these well in his influential blog post “Product vs. Feature Teams“:
Specifically, [product teams] are cross-functional (product, design and engineering); they are focused on and measured by outcomes (rather than output); and they are empowered to figure out the best way to solve the problems they’ve been asked to solve… [but] much more often than not, the teams are not empowered at all.
A team that builds line item after line item from sheet after sheet is a team that quickly feels it’s on an endless assembly line – because it is: product writes a specification, design translates it visually, engineering builds it, QA tests it, marketing sells it. Next.
If you had a cross functional team that instead tackled business problems, things’d be very different:
- Inherent to the idea of solving a problem is making explicit assumptions, forming hypotheses, building in order to test those hypotheses – otherwise how does one know one is successful?
- That leads to learning – what works and what doesn’t – so the next thing the team takes on is more likely to succeed with customers, and so on. That leads to momentum – the holy grail for any product.
- And finally, teams that are cross-functional learn collectively instead of it residing in an individual, or being lost.
Such teams are rare because of the belief that solid roadmaps are what make management dashboards look good.
There are two important caveats to this:
First: Most DTC products will go though alternating phases of build and optimise. My experience is that companies spend far too long building and too little optimising. You build when you spot – and validate – a new opportunity: expanding into adjacent market or an externality like a welcome change in regulation. You optimise to get this right. Build is when a short list of features is in order. Optimise is when you solve problems.
Second: The problem-centric approach doesn’t apply to the early stages of a new product or a startup, where the point is to create and put out in the world something tangible. But once it begins approaching product-market-fit, leadership needs to make the shift from feature to product teams.