High-performing product teams: Building products customers love, at high speed

I have been intrigued by what makes the top tech companies in the world able to consistently deliver solutions that customers love, at such high speed. Fortunately, this knowledge has been well documented and shared in various ways — from tech startups to massive enterprise case studies. Combining this information with multiple conversations with people from the industry and my experience in Product Management so far, I have learned that there is a profound difference in how high-performing tech companies develop products compared to most companies. Everything from organizational design, corporate innovation capabilities, leadership behaviors, level of team empowerment, product development processes, product team structure, roles, dynamics, and product discovery techniques; to organizational culture.

This article summarizes some of these differences.

Corporate innovation engine

There is something seductive about success. It lures people to continue doing what they’ve always done. And that is not just a cultural issue in many organizations. The main problem is how these large organizations are usually designed for innovation.

Innovative high-performing product teams typically have a fast innovation rhythm and pace. They know how to build products and they know how to apply lean innovation methodologies from discovery to delivery. However, an inefficient organizational system in a large enterprise will beat a well-trained product team any day… You can’t beat the system. Corporate innovation researchers like to call this rhythm misalignment. Indeed, startups are designed for fast innovation and they are typically focused on succeeding with one main idea. In contrast, big organizations are faced with a myriad of concerns such as exploration vs exploitation, search vs execution, create vs manage, deliberate vs emergent strategy, etc.

Nevertheless, it is easy for an Agile enterprise that is able to consistently innovate at high speed to beat a startup any day.

As mentioned by Tendayi Viki,

“A large company is not a startup, nor should it strive to be.”

Yet, to build an innovation engine requires that organizations change how they develop their innovation strategy, make investment decisions, measure progress, incentivize intrapreneurs (corporate entrepreneurs), and develop products.

Managing established products can be done using traditional management tools such as return on investment (ROI), net present value (NPV), and internal rate of return (IRR). However, it is highly recommended that the development of new products is managed using startup methodologies, such as experimentation and iteration. Here, success is measured by how well the product team is doing in their quest for profitable business models and solutions that solve customers’ problems.

The most common way of doing this is through metered funding or incremental investing — where each round of investment has specific objectives. As product teams show progress, they proceed in getting follow-up investments. The initial small investments allow leaders to learn whether the product has potential. By moving from assumptions and gut feelings to evidence, they validate whether the solution solves a customer problem and if the customer will pay for it. They also validate whether the business model is capable of creating and capturing value. Since the early stages of any innovation journey are mostly about market validation (from different standpoints), companies can achieve their market validation objectives with very little money invested — especially if the product or innovation team is competent.

As ideas start to get traction, companies can then make larger investments to achieve product-market fit and scale the product.

This is very different from the traditional business case model where teams have to complete a detailed case to justify the proposed project with 5-year projections, sometimes even longer.

Regardless of how elaborated the business case might be, it boils down to two foundational inputs: How much money will the company make and how much it will cost.

The cold truth is that the teams have no clue of either one of these in early-stage developments.

“Five-year revenue projections for new and untested ideas are fiction.”

Product teams know this, and so does management. But it’s a conventional ritual that product teams must follow. So people play the business case game. If not, no money for you.

Products over projects

Thus, some corporations like to have very structured product roadmaps as well as a clear system to rate all these potential projects.

Historically, when Agile started to prove its value in the tech industry, a few large companies managed to gradually transform their ways of working. Yet, many companies are still organized based on projects rather than products. They like to fund projects, staff projects, prioritize projects, and finally launch projects. So in these organizations, what you may be seeing is Agile for Delivery. The rest of the product development and innovation is anything but Agile. The reality is that most companies still have a process that is essentially waterfall at its core. Some of these organizations claim to be Agile since they have embraced some of its tools (e.g. SCRUM). “However, the Taylorist factory mindset remains.”

They introduce sprints but there is no less planning involved. They claim to build Minimum Viable Products (MVPs) but there is no less documentation to write. They recruit Product Owners and Scrum Masters but their software releases are still dependent on a manufactory-like Change Management process. They may have a Product Team but the decision-making is still centralized within multiple stakeholders.

Missionary vs. mercenary

High-performing product teams understand the business objectives and context. They feel ownership and responsibility for the outcome. Instead of focusing on “finishing” the development and ship something out the door, they don’t rest unless the product has met the business objectives and defined outcomes.

Rather than being measured on the output of their design work, product designers are measured on the success of the product. Together with the Product Manager and Tech Lead, they make sure a strong product is built, time-to-market is reduced for each iteration, the customer problem is solved and the business result is met.

These teams agree on what progress means for them, make sure they are measuring it, debrief regularly, and set actions for improvement. They have a clear product vision and strategy which they pursue with a missionary-like passion.

In contrast, conventional teams are project mercenaries and output-driven. They focus on delivering a roadmap that is grounded in a “feature factory” philosophy, as well as assumptions that were never validated until global product launch.

Outcomes over outputs

In traditional management models, conventional output-driven roadmaps have been established for two main purposes:

• Assure management that the different teams are developing the right things with the highest business value first;
• Deliver specific dates for allowing date-based commitments.

Yet,

“Typical roadmaps are the root cause of most waste and failed efforts in tech product organizations.”

The main problem is not the list of ideas that go into it. The problem is that anytime you add anything that is output-related to a document called a “roadmap”, people across the company will perceive it as a commitment — especially when tagged with a rigid delivery date.

Another pitfall of output-based roadmaps is their charming ability to make people fall in love with the proposed solution, rather than the problem that it’s trying to solve. This love can grow strong especially in teams with slow Time-to-Market (TTM) where the same solution lives in a PowerPoint presentation and high-fidelity prototypes for years. As it is statistically more likely that your initial solution will fail than succeed, this can have a dramatic impact on both the team and key stakeholders’ morale, as well as on the business.

For technology companies, however, the focus shifts to:

• Vision and strategy for each product;
• Specific and prioritized business objectives for each product team.

Management provides each product team with the specific business objectives they want to tackle. The teams are empowered to try and find out the best solutions to meet such goals. This empowerment is key, for several reasons:

• First, teams will be more motivated when having some degree of accountability and freedom;
• Second, assuming these teams are made of competent and dedicated people, they are the ones in the best position to tackle these challenges;
• Third, in software, things will not work out as planned quite often. The team must learn from these experiments and try other approaches until the business goal is met.

It’s all about the outcome they want to achieve, not the output. This is why Objectives and Key Results (OKRs) are so important and the reason why almost all top tech companies today have adopted them (including Google, Facebook, Twitter, Amazon, MSFT, Slack, and Netflix).

While the concept of OKRs sounds straightforward, many practitioners have mentioned that it took them some time (usually a few quarters) until the organization got the grip of it.

In early-stage startups, for example, implementing OKRs is reasonably easier as the product team is essentially the whole organization, with the founder typically acting as a Product Manager. For enterprises with multiple Business Units, you would expect corporate-level OKRs with Business Unit-level OKRs and with the product teams’ OKRs rolling up into those.

Continuous delivery

High-performing tech product teams nail the very fundamental concept of continuous delivery — a series of small, incremental changes to a complex system. They understand that a constant stream of releases provides a much more stable build for the users, allows for continuous hypothesis validation and iteration, reduces risk, reduces time-to-market, increases the probability of success, and leaves their customers asking for more.

Conventional teams follow old waterfall models where the market drives the functionality (a.k.a. requirements) which leads to design (concept) that drive the development (implementation) — with little or no collaboration between team members and releasing everything at once, after a 1-year project and hundreds of pages of irrelevant documentation.

Co-location and team dynamics

Today, we know that functionality, design, and technology are intertwined. High-performing teams have product, design, and engineering side by side to make sure they validate the technical feasibility of their ideas continuously during discovery, not after. They also assess business viability (e.g. pricing market fit, business model) continuously during discovery, not after.

“All the other things being equal, a co-located team is going to substantially outperform a dispersed team. That’s just the way it is.”

And that means that team members are literally sitting right next to one another.

On the other hand, conventional teams work in silos, team members don’t collaborate, make big decisions individually, are not co-located, and only show the concepts and prototypes to engineers during sprint planning to get estimates.

Product discovery

High-performing teams are competent in modern discovery techniques and are capable of creating user prototypes at all fidelity levels (from wireframes sketched out on paper to live-data prototypes) and perform several iterations a week. They establish a routine of customer interviews as well as a fast and effective mechanism to document and share their learnings. More importantly, they link their continuous discovery with their backlog items making sure the right things are being prioritized — at all times.

Conventional teams are still waiting for permission to run a simple test and tend to focus on delivering the already approved roadmap, with no questions asked.

High-performing teams understand that qualitative testing is all about rapid learning and relevant insights — not about proving anything. If collecting evidence is what they are looking for, they know quantitative techniques are more appropriate. This is especially important when assessing customers’ willingness to pay (WTP) and testing business models — which they start doing as early as possible, not when the product is already designed or developed.

They understand that great ideas are not enough. Successful innovation is all about turning great ideas into great businesses, with a sustainably profitable business model that can create value for their customers and company.

On the other hand, “where a lot of novice product people go sideways is when they create a high-fidelity user prototype and they put it in front of 10 or 15 people who all say how much they love it. They think they’ve validated their product, but unfortunately, that’s not how it works.”

Link this together with the previously mentioned project mercenary output mindset, lack of clear goals, and ineffective team dynamics; and you might have the recipe for failure in the digital era.

Product culture

As Ben Horowitz puts it,

“Culture isn’t a magical set of rules that makes everyone behave the way you’d like. It’s a system of behaviors that you hope most people will follow most of the time.”

Although companies can go a long way by changing their processes when attempting to change their product cultures, Agile methodologies alone will not enable businesses to consistently innovate. Apart from an accountability framework that balances autonomy and alignment, innovation needs a dedicated and different incentive system too.

Organizations need to design a product development culture that gives them the advantages they need, creates an environment they are proud of, and can actually be implemented. Modern innovative giants that have managed to institutionalize innovation practices understand they cannot have the same incentives and reward system as the core business. If culture is defined as a set of actions — the actions they value need to be incentivized and rewarded. But to reward, companies need to start measuring the right things. Different types of innovations require different types of measurements.

Here are a few common cultural traits in high-performing product teams:

• Culture of evidence — A test-and-learn environment requires an evidence-based culture. High-performing teams don’t get tired from hypothesizing, experimenting, collecting data, measuring results, and use outcomes to guide the next steps.
• Culture of open minds — There are a lot of incredibly talented people in every organization. Good ideas can come from everywhere. Great teams know how to listen and collaborate.
• Culture of empowerment and shared accountability — This is teamwork 101. Great teams feel empowered to make decisions and feel deep accountability for the products’ success. This certainly also applies to product failure. Here, however, in extreme and repeated situations, the Product Manager should stand for the team — just like a captain would do in team sports.
• Culture of skill-set and transparency — good teams appreciate the different backgrounds and experiences of their team members. They also know where there might be room for improvement. If they can, they will help each other develop those skills.
• Culture of speed and urgency — this is key in software development. Good teams know exactly how to conduct product discovery effectively and responsibly, combining different techniques. They understand that if they do not move fast in both discovery and execution, bad things can happen to the organization.
• Culture of business — good product teams understand that they are part of a business, not an R&D atelier. They do not rest until the business goal is met, and they try to minimize the time it takes for that to happen.
• Culture of learning — the best teams celebrate failures as long as they have learned something that will help them achieve their goals. They are obsessed with learning from customers, the market, stakeholders, team members, and colleagues from every single department. Everything they do has a learning objective.

Without strong product teams, time-to-market increases — as well as the Cost of Delay (CoD) associated with it — market opportunity decreases, and poor solutions emerge. With poor solutions, customer acquisition costs (CAC) are too high, sales organizations need to put in an extra effort to close deals driving up costs of sales, pressuring prices, and lengthening the sales cycle. Moreover, customer success departments are forced to double the efforts every day with frustrated customers.

When customers are not happy and sales are going down, the brand loses recognition, market share starts to drop as well as brand loyalty (double jeopardy law). Moreover, frustrated customers often result in sales and specific accounts coming up with the product requirements. This contaminates the product teams’ ability to focus on real discovery. And when products are being developed based on specific accounts’ requirements rather than effective discovery and product strategy, poor solutions emerge. It’s a tragic virtuous cycle.

On the other hand, dedicated, talented, passionate, and well-trained product people build solutions that customers love. This helps transform many organizations whilst playing a crucial role in enabling them to achieve their goals — and ultimately, the company vision!

Main references:

• Inspired: How to create tech products customers love, Marty Cagan
• Project to Product, Mik Kersten
• Pirates in the Navy: How innovators lead transformation, Tendayi Viki
• Designed for Digital: How to architect your business for sustained success, Ross et. al.
• Escaping the Build Trap, How effective Product Management creates real value, Melissa Perri
• The Lean Product Playbook: How to innovate with minimum viable product and rapid customer feedback, Dan Olsen
• Monetizing Innovation: How smart companies design the product around the price, Madhavan Ramanujam
• What You Do Is Who You Are: How to create your business culture, Ben Horowitz
• Radical Focus: Achieving your most important goals with OKRs, Christina Wodtke
• Agile Conversations, Douglas Squirrel and Jeffrey Fredrik
• The Startup Way, Eric Ries