Product failure is expensive — here’s how to avoid it

Product failure is expensive — here’s how to avoid it

Here in the U.S., every product team represents, on average, approximately $1-2 million a year of investment, according to Glassdoor. And, depending on whose industry data you value most, anywhere from 60-95% of features built are never used because they do not solve important needs. This adds up to a staggering loss of $600,000 for every product team per year. 

This doesn’t even account for the size and scope of your organization — does your company have 5, 10, 20, or 100 product teams? If we imagine it’s the latter — you’re spending, at minimum, $60 million a year building stuff that nobody needs (or evidently even wants).

There is absolutely a way to achieve much higher R&D returns. It requires a modern approach to product management — one that puts the customer at the center of the process — but more importantly, assures that everyone on the product team understands what customers actually need.

What’s lost to poor collaboration: an origin story

I started Productboard in 2014 with the goal to help all software makers create extraordinary digital experiences. This may sound obvious, but consider this statement against the backdrop of our current IT landscape: Gartner found that technology spending within the software sector was at $675 billion, up 9.8% from 2021. Spending hasn’t slowed, but neither has the need for technologies that can help us work better and faster — essentially transform the way we work.

“Spending hasn’t slowed, but neither has the need for technologies that can help us work better and faster — essentially transform the way we work.”

When I say helping all makers, I mean all people who are involved in the product management process — engineers, product managers, designers, user researchers, product marketers — anyone who participates in understanding customers and devising awesome products to satisfy customers’ needs. How they work together is critical to the success of companies.

My motivation to bring all these folks together stemmed from my personal frustration of working at a company where talented Product and Engineering teams were not on the same page, and by extension, not living up to their potential. Not to mention, I love engineers — I got a Masters in Computer Science, and have a soft spot for engineering tools. I also know how well-intentioned and sophisticated engineering-led organizations are, while often being subjected to blame (when there’s typically plenty to go around). It had nothing to do with their immense talent, but rather what became an inconvenient truth – they didn’t have a shared understanding of customers and their needs. Raise your hand if any of the following sounds familiar:

  • Engineering was pushing technical agenda, while Product had an isolated roadmap that they seemingly pulled out of nowhere
  • Engineering was frustrated by lack of clarity in product specifications, while Product was frustrated by a lack of thoughtful features that deliver meaningful customer value
  • Engineering optimized their process and productivity, but they lacked the empathy and knowledge of what really mattered to customers, while Product had that understanding, albeit isolated and in a vacuum that began and ended with them
  • Within our Agile methodology, Engineering had JIRA for task management (which worked great for them), but did not necessarily translate to their collaborators

The result? Product was being built, Engineering productivity metrics looked great, story point throughput was high, quality metrics were high, but the resulting product did not live up to expectations. 

Worse yet, Engineering blamed Product and Design for poor specification and a lack of guidance. Meanwhile, Product and Design blamed Engineering for piling up technical debt, making poor architecture decisions, and over-engineering functionality. It’s not as if there weren’t engineering tools that could help, such as JIRA, Azure DevOps, or GitHub, but their strengths lean towards organization and building features faster at scale, and not quite guiding us to prioritize building the right features.

“We were wasting our lives building a product that nobody was proud of, all at the expense of the business.”

Needless to say, it wasn’t great. In fact, it was incredibly frustrating. Personally it didn’t feel great to work in such an environment, but what’s worse it created an enormous amount of waste. Basically, we were wasting our lives building a product that nobody was proud of, all at the expense of the business.

>>Related: 7 ways to improve your designer–PM collaboration

Product and Engineering teams in sync? Yes it’s possible

The massive opportunity we have ahead of us as the digital industry isn’t to build more engineering tools — it’s to enhance the best ones that already exist by bringing customer understanding to the center of the product management process.

That is why I started Productboard, because I realized the immense value that can be created if teams centralize customer insights and use them to guide the product management decisions. That is why in Productboard, entire product teams can centralize all data about their customers and insights about their needs and pain points.

“The massive opportunity we have ahead of us as the digital industry isn’t to build more engineering tools — it’s to enhance the best ones that already exist by bringing customer understanding to the center of the product management process.”

And that is also why the roadmaps in Productboard are backed by customer context — and better yet, anyone can easily see and justify why something is or isn’t on the roadmap. If an engineer struggles with making a decision, they can go into Productboard and immediately see who is going to benefit from a specific feature, and read snippets of customer conversations that provide deep context. Such context is critical to understanding the customer expectations, how the feature might evolve in the future, and how that all translates to an appropriate architecture investment.

That doesn’t mean that we shouldn’t use engineering task management tools in order to build code efficiently. We absolutely should. But, we also need to complement those tools with product management tools.

>>Related: How GSoft shared and solved customers’ problems collaboratively, increasing productivity along the way

The ROI formula for product success already exists

Picture this: if that $600,000 in product waste was spent on solving burning needs of your customers that they can’t satisfy with any competing product, what exponential impact would it have strategically for your business?

This kind of thinking isn’t radical — it’s absolutely table stakes in other areas of your business. Take marketing, which is measured by how much pipeline is generated per dollar spent. A common metric for success is directly related to the customer acquisition and retention: Lifetime Value (LTV) to Customer Acquisition Cost (CAC), where a ratio of 3:1 or better points to a sound strategy.

There is no reason we cannot apply the same thinking to our product investments in terms of the value we create for our customers and the amount we capture for our business. How incredible would it be if we saw a 10x return on our R&D spend?! Imagine that if the $600,000 of one team’s cost that goes wasted was turned into $6 million of value created? We are talking about a massive upside.

This isn’t a pipe dream, either — we’ve seen an intentional approach to streamlining Product and Engineering workflows do wonders for companies we know well (Slack, Spotify, Zendesk) and others that have been benefiting from this strategy for years (Prospecta, Zapier).

“If the entire team has a deep understanding of the customers and their needs, they can have all the context they need to make the right product, design, and architecture decisions.”

The democratization of digital product management means that everyone on the product team makes decisions — product decisions, design decisions, engineering architecture decisions, product marketing decisions — it is impossible to capture everything in a spec upfront. And in those decisions lies the biggest risk, but also the biggest potential. If the entire team has a deep understanding of customers and their needs, they can have all the context they need to make the right product, design, and architecture decisions. And if they don’t have a shared understanding? Well then we’re back to where we started — seeing the crazy high waste rate in the industry — and the guarantee that you’ll be set up to fail.

A modern approach to product management requires us to embrace the JIRAs and combine them with complementary collaboration tools (such as Productboard) in order to break down silos between product, design, engineering, and product marketing. It also requires a process and a system that puts a deep understanding of customers at the center of the product management process, and in turn, a shared understanding across the entire product team that will generate returns for years to come.

You might also like

Best Practices for Better Product Feature Prioritization 
Company & Product

Best Practices for Better Product Feature Prioritization 

Productboard Editorial
Productboard Editorial
Product-Led Growth Strategy: Practical Implementation
Company & Product

Product-Led Growth Strategy: Practical Implementation

Productboard Editorial
Productboard Editorial
Top Product Discovery Techniques
Company & Product

Top Product Discovery Techniques

Productboard Editorial
Productboard Editorial