Changing How You Solve Problems

By Jon Moore and Marty Cagan

This is the second of a three-part sequence on defining transformation.

Changing how you build, test and deploy is important no matter what you choose to build, but for too many companies, they just become a more efficient feature factory.  They ship more new features than ever, yet they don’t see the corresponding value to their customers, and impact to their business.

In fact, in most companies, the percentage of features and projects that are on your product roadmaps today that actually generate a positive return on investment is depressingly small.  Most industry analysts place it in the 10-20% range.

If you compare the list of capabilities that your company needs, with the impact that your newly released capabilities are generating, and if you are not feeling good about the return, then this is why changing how you solve problems is so important.

The root of the issue is that these feature teams are set up to serve the stakeholders in your business, rather than to serve your customers in ways that work for your business.

The business leaders and stakeholders each understand their specific needs, and they come up with a list of features and projects that they believe will help them deliver on their obligations to the business.  They hand these priorities down to the feature teams who are then asked to provide a product roadmap with dates and deliverables.

So why do so few of these features actually generate the hoped for return?

Realize that each of these features is a potential solution to some underlying problem.  It might be a customer problem – maybe customers can’t figure out how to effectively use our product – or it might be a company problem – maybe it costs us too much for us to provision our product.

In the feature team model, the feature on the roadmap is designed by the designer on the feature team, and then built by the engineers on the feature team.  But the value and viability of the feature itself is the responsibility of whomever requested that feature on the roadmap.

This is why in the feature team model you can’t hold the feature team accountable to business results.  They are only there to produce output – the features.  If a feature doesn’t generate the desired outcome, they will simply point out the fact that this was not their job.

Now it’s also very true that the stakeholder that decided on this feature will not likely want responsibility for the failure either.  They’ll almost certainly complain that the feature that was shipped was not what they had hoped it would be, or that it took longer to deliver than they had expected.  Which is why lack of trust between stakeholders and feature teams is such a common complaint.

Another serious consequence of this way of working is that we end up with a great many “orphaned” features – features that don’t produce real value, but are waiting for the day they might get another iteration, which rarely happens.  The result is very fast accumulation of technical debt, which can quickly get out of hand and end up dramatically slowing down the feature teams, or in some cases bringing the business to its knees.

For whatever reason, as soon as you lose your ability to consistently create value – to innovate on behalf of your customers – it is only a matter of time until your competitors are able to offer a more compelling solution to your customers.  This has happened to countless companies.  

You can reduce your prices, and you can run clever marketing and sales promotions, but these measures at best will just delay the inevitable.  Eventually someone else will serve your customers in ways that you no longer can.

SOLVING PROBLEMS FOR OUR CUSTOMERS AND OUR BUSINESS

Let’s contrast this with an empowered product team.  In this case, rather than providing the product team with a roadmap of features and projects to build, the product team is instead given a set of problems to solve and desired outcomes to achieve.

Rather than simply implementing the features desired by the stakeholders, in an empowered product team, the product team is tasked with coming up with a solution that works for both the customer and for the business.

This means coming up with a solution that is valuable – the customer will buy or choose to use; usable – the user will be able to figure out how to use; feasible – our engineers know how to solve with the time, skills and technology on the team; and viable – the solution will work for our business in terms of constraints in marketing, sales, finance, service, legal and compliance.

So why is an empowered product team necessarily any better than feature teams?

Besides the obvious reasons such as morale resulting from a much greater sense of ownership, and the knowledge gained in testing potential solutions directly with our users and customers, the major reason is because strong product companies understand that the single most important source of innovation is actually our engineers, and empowered product teams are designed to tap into this powerful asset.

In a feature team, the engineers are simply there to build what is requested.  They are effectively mercenaries.  Even worse, if you outsource your engineers they are quite literally mercenaries.  

But in an empowered product team, the engineers are not just there to build, they are also responsible for helping to identify the right solution.  This is what is meant by the term empowered engineer.

The advantage that the engineers have is that they are working with the enabling technology every single day, which puts them in the ideal position to see what’s just now possible.  

When these empowered engineers are exposed directly to users and customers, you can start to see where nearly every innovative product or service you love originates from.

As Steve Jobs famously said, “we don’t hire all these engineers to tell them what to build; we hire them to show us what’s possible.”

When combined with a strong product designer trained in the craft of designing effective and engaging user experiences, and a capable product manager trained in understanding both customers and the constraints of your business, you have the cross-functional set of skills necessary to solve hard problems in ways our customers love, yet work for our business.

PRODUCT DISCOVERY AND REDUCING TIME-TO-MONEY

For an empowered product team held accountable to results rather than just shipping features, while time to market is still important, what is most important is time to money – in other words, the time to achieve the necessary outcome.

If an empowered product team ships a feature but does not see the necessary impact, then they iterate on that feature or on their approach until they do.

With this as the goal of the product team, the incentive moves to being able to quickly determine if a particular product idea or approach will work.  This is referred to as product discovery.

The product team could simply build their various ideas and see what works, but this would take much more time and essentially use our customers as guinea pigs.  Instead, the product team has a full battery of tools and techniques in order to quickly test out ideas and approaches.

Mostly the product team creates prototypes, which come in various forms but all are very fast and inexpensive to create, and each type designed to test different risks or assumptions.

The general rule of thumb is that any idea tested in product discovery should be at least one order of magnitude less expensive and faster than using the engineers to build, test and deploy an actual product.  In many cases, the prototypes are two orders of magnitude less than the product.

If, on average, it takes 3-5 iterations for a typical feature to reach the point where it generates the necessary business results, and if a feature team is being used to build each of these iterations, then we are often talking on the order of 1-2 years before a feature generates the desired returns, and that’s only in the rare case the stakeholders are willing to continue to put these necessary iterations on the product roadmap.

In contrast, if the empowered product team is assigned the problem to solve, and staffed with the skills needed to perform product discovery, then those 3-5 iterations can happen in 1-2 weeks, and the product version is in customer’s hands generating the necessary business results usually a few weeks after that.

If you’ve ever wondered how small, empowered product teams can so consistently out-produce much larger companies spending much more on their feature teams, this is right at the heart of the answer.

TRUE COLLABORATION OF TECHNOLOGY AND BUSINESS TO SERVE CUSTOMERS

Beyond saving money and time, the more important benefit of changing how you solve problems is that you are creating the mechanism to consistently create value for your customers.

Instead of feature teams there to serve the stakeholders in your business, you now have empowered product teams designed to serve your customers, in ways that work for your business.

This difference is not minor, and changes the dynamics of your organization.  

But be warned:  

Some key stakeholders will not be happy about losing control over the technology resources.  It is likely that many will resist passively, and some actively.  Which is why without the active support from the very top of the organization, transformations so often fail.

Also, some of your current product managers, product designers, and engineers may not be willing or able to take on this additional responsibility.  It is much harder to take responsibility for solving customer problems, than it is to just build the features you’re told.  You will need to ensure that you have staffed the right level of people on your product teams, and that they are provided with the necessary coaching for them to succeed.

Strong, cross-functional, empowered product teams of product managers, product designers and engineers working together to solve customer problems in ways that our customers love, yet work for our business, is the essential core competency of a product-led company.