Wouldn't it be cool...

why we keep on building the wrong things

I’m still astounded by how many people in software fall in love with their solutions before ever understanding what customers want. No customer delighting feature ever had its roots in the phrase, “Wouldn’t it be cool if…”

Solve Problems

Too often, a software team builds “a thing”, and that “thing” - while potentially cool - doesn’t help the users of the software get their problems solved. I have worked on software used by millions of people, and I’ve still seen this happen far too many times.

Building the wrong thing isn’t the only way we fail in solving customer problems. For a minute between 2000 and 2003, I worked on Windows CE (a tiny footprint OS that in some ways, was ahead of its time). A few months before I left the team, I was talking with our Director of Program Management, who walked me through a wide variety of new networking features and enhancements planned for the next release. CE had been used in a tiny number of home network devices before then, so I excitedly asked which customers were going to be using the new features. His reply was, “We don’t have customers for all of this stuff - we just have a lot of people on the networking team to keep busy.” I left the team shortly after, but I don’t recall even half of those features making it to the next release. Surprisingly, there were two more releases after that before the product faded away.

I worked on another product at Microsoft where the leader of the project would go straight to developers and ask them to implement a feature he thought was cool. As dumb as the requests were, a mid-level developer saying “no” to an SVP wasn’t a smart move. So - we ended up with a bunch of stupid stuff in the app. I left the team when I couldn’t stand to watch it anymore.

Finding Balance

I talked about customer-centric development before in this post. A lot of the same points in that article as I’ve stated above that basically sum up to this statement from The Lean Product Playbook:

As Dave McClure of 500 Startups said, “Customers don't care about your solution. They care about their problems.”

A lot of folks insist that they have to “innovate” and build fancy new things rather than wait for their customers to ask. While there’s ample room for innovation, you have to balance innovation with making the current stuff work better.

A long time ago, I learned about the Kano Model - which looks at customer value from different dimensions. A common representation looks like this:

I’d credit the site I stole this from if it still existed

Like all models, this one is wrong, yet useful. What I find useful is in using it to balance Delighters (features or attributes that customers may not expect but can pleasantly surprise them) with Satisfiers (more below). Delighters are where we can identify opportunities for innovation or for differentiating features. Kano also states that it’s essential not to overinvest in delighters, as they may lose their novelty over time and become expected features.

Satisfiers, on the other hand are essential features that customers expect, and they’re happy when those features meet their needs - but are dissatisfied the moment those features do not meet their expectations.

The Kano model can be used to help find balance between the things customers need and the things that may solve their problems in new ways. If you screw up with the satisfiers, the delighters won’t matter.

Product Led

There has been a lot of talk and writing recently on “Product-Led” teams. As happens in software (and maybe in life, too often), people only read the headline and not the article. Product-led doesn’t mean that the Product Management team is in charge, it means that the Product is the driver of customer acquisition, retention, and expansion.

In a product-led team, the Product Manager is the curator of the product, and they focus on aligning the team on the customer problems they need to solve. This approach is intended to focus the entire team (developers, product managers, and even intrusive SVPs) on solving customer problems.

In Trillion Dollar Coach, the authors say this about famous Silicon Valley executive coach Bill Campbell:

Bill told the poor product manager, if you ever tell an engineer at Intuit which features you want, I’m going to throw you out on the street. You tell them what problem the consumer has. You give them context on who the consumer is. Then let them figure out the features. They will provide you with a far better solution than you’ll ever get by telling them what to build.

This is the way of product-led.

The Build Trap

Melissa Perri’s, Escaping The Build Trap summarizes many of these concepts extremely well. She describes the difference between technology-led (driven by the latest and coolest technology - who often spin their wheels producing lots of very cool things with no buyers) - and product-led (optimize for business outcomes and growth). She says:

The real role of of the product manager in the organization is to work with the team to create the right product that balances meeting business needs with solving user problems.

This book covers a lot of ideas and strategies to help focus on delivering outcomes that solve real customer problems and address their needs, rather than just adding features for the sake of it.

Looking for Patterns

Last week I said:

I feel like there are folks out there so invested in testing that they value good testing of a bad product over building a good product.

…and in writing this post, I have to wonder if there are folks focused on making things rather than solving customer problems. So I’ll ask this to my software developer friends.

The thing you’re working on right now. Is it a thing that solves a well understood customer problem - or is it a thing that someone on your team - or you - thought would be cool to build?

-A 2:3