The Product Development Strategy Guaranteed to Delight Your Customers

Imagine you were building library databases for schools.

The librarians are your economic buyers, and they value advanced search pages—Boolean searches for just the right keywords or publication dates. But the librarians aren’t buying these databases only for themselves.

Instead, they’re buying them for high school students. Students who don’t have a master’s degree in Library Science, who probably don’t know or care about Boolean searches because they’re used to using Google.

If you only considered the economic buyers’ wants, do you think you’d end up building a suitable database? Do you think your database would get widespread adoption from the end users, a.k.a. the students you and the librarians were hoping to get?

Probably not. On the contrary, if you assumed that the buyers’ values matched those of the end users, you’d likely look back and see this product as a total fail.

“No one’s using our product? But why?”  

“If only we knew what we needed to build ahead of time, we could’ve built the right thing the first time.”

This library database scenario exemplifies how making a big assumption, even in a relatively short decision chain, can disrupt your ability to deliver a high-quality product that will delight your customer.

This same type of scenario plays out in business all the time, too. But, in business, we often deal with more significant decisions, longer decision chains, truckloads of more money, and people’s livelihoods on the line. The fallout of making a poor decision about the product you’re building can get costly from both a human and financial perspective, so it behooves us to figure out some way to get it right.

Fortunately, there’s a way to weed out poor product assumptions early in the build process to mitigate risk, reduce waste, and save some dollars and heartache along the way.

But first, let’s look at how product assumptions can creep into our work.

Product Fit: The Hunt for Red Herrings

We’re unsure how red herrings became synonymous with a false or misleading clue. Maybe if we had some sort of advanced Boolean search to help us find the answer—wait, erm—we’ve been down that path already, haven’t we? Alright, we don’t have to go there again.

But product assumptions are, in fact, red herrings, though. They lurk inside your organization, just waiting to sabotage your product, and they can come from many different locations: sales, marketing, Ops, finance, you name it. Heck! Even talking to your actual customers sometimes isn’t safe.

Sales may say, “Look. Our competition has 20 features, and we only have 10. We look bad by comparison, and it seems to be a sticking point in most of my calls. We’ve got to build in more features. Pronto!”

Or marketing might tell you, “Hey, bud. We’ve been doing market research, and the customers are looking to solve problem X, and they want this very specific feature that’s incredibly heavy and complex. Still, we think you need to build it because, hey…the customer is always right.”

Or even worse, maybe your SVP ambushes the teams one day and exclaims, “Everyone! Today is a new day for us. We will begin the launch of Our Product 2.0! It came to me in a vision last night as I lay there deep in my slumber. It’s going to be great! Just. Trust. Me.” *commence eye rolls*

Okay, that last one might include a little hyperbole, but you get the point. These assumptions can come from anywhere, at any time. But you know the old saying about assuming, right?

Are All Product Assumptions Good or Bad?

 But Derek? But David? Aren’t we supposed to be innovative and inventive so that we might push the boundaries of the market to keep up with our competition?

Glad you asked. Absolutely. You want to be both innovative and inventive in a competitive marketplace. And especially in new markets. We’d even go as far as saying that in new markets, sometimes all you have are assumptions and hypotheses.

So, it’s not that all assumptions are good. And it’s not that all assumptions are bad. It’s the wrong question to ask. The truth is that assumptions are reality. Often necessary.

So, the question is how we can create a product roadmap enabling us to test our assumptions. How do we get fast feedback from the people who matter to ensure we’re investing our time, energy, and dollars into the right places, at the right time, to release the most value into the market and get the most ROI?

And how do we do these tests and get the feedback at scale without losing our ability to be Agile?

Because if you’re not asking the right questions and thinking about your products in investment increments, you’re doing it wrong, and you’re going to run into product fit issues. And product fit issues lead to rework or, worse, tearing it all down and starting from scratch.

That’s a lot of wasted time and money. Not to mention a lot of unhappy customers.

And the only people you end up delighting are your competition.

Your competition? They love to see you fail.

 The Product Strategy You Want & Need

 How do you not delight your competition and delight your customers instead?

It’s easy. Make smaller bets.

First, what do we mean when we say make smaller bets? We mean that it’s always easier to build more. You can always add a feature later. But if you’ve already built it, you can do nothing to get that time, effort, and money back.

In Agile, the delivery organization inside your business strives to reduce batch size and deliver an increment of working-tested product that has some value to the business or its customers at the end of every sprint.

Your product organization must work similarly. The product organization can’t say we’re going to build this suite of features based on these hypotheses, then turn around and wait eight months before a customer ever gets a chance to lay eyes on it. That’s Waterfall.

In our experience, most people hip to Agile understands the Dev teams’ work intuitively. Epics decompose into features. Features into stories. The work flows through some tiered governance model. The delivery teams are rapidly putting increments of tested products on the market. Typically, we see some automation to mitigate the risk of escaped defects. Pretty standard.

But how do you do that with a product assumption? The names and faces may look a little different for product organizations, but they have the same principles. We’re looking to quickly get a lightweight version of the assumption—an MVP if you will—in the market. We want to validate that assumption with real people as fast as possible and then apply what we learn to the next batch of work.

How Agile is Your Product Organization?

If you want your product teams to be more Agile, there are three critical categories they should focus on: prioritization, prototyping, and metrics.

Prioritization  

Most organizations don’t lack ideas. There are a ton of ideas inside every organization. And when you have a ton of ideas, you need a way to prioritize them that isn’t just a gut feeling. You need a methodology that uses metrics and data to help you decide what to build and when to build it.

Every organization is different, but your criteria might be something like Business Value to the organization + Business Risk Metric + Level of Validation Required = Proceed or Holdoff. Whatever your specific criteria are, you must have a way to marry the art and the science of product development to ensure you make the appropriate level of investment.

In a company full of ideas, people are going to have opinions. And developing a methodology to prioritize what you’re going to build will enable you to keep the feelings out of it, have value-based conversations as a team, and ultimately make better decisions for the business.

Prototyping

Remember when we were talking about an MVP assumption earlier? That’s what prototyping is. Things inevitably cost more as they move down the product line. The goal of prototyping is to create the most realistic façade of the product you can without actually building it so that you can get feedback from your customers.

Think about the old-timey towns in Western movies from the 60s. The sets would only include the fronts of the buildings. As an audience member, you got 10% of the buildings but 90% of the experience. We’re doing the same thing.

We want to give our customers 90% of the experience. Just enough usability. Just enough navigation options. Just enough so we can see how they interact with it and use it when left to their own devices.

You can prototype in Photoshop, PowerPoint, Keynote, InVision, or Figma. Regardless of how you build a prototype, it needs to be lightweight, cost-effective, and take up the least amount of bandwidth possible from the rest of the organization.

Once you validate your assumption with the customer, you can begin the technical work, get Ops involved, and Support when necessary. You want to be careful you’re not jumping down the product line too early.

Metrics

Metrics are tricky due to every organization’s unique structure, values, risk tolerance, and current reality. That said, understanding things like feature development cost, customers gained, feature usage, and revenue are safe bets, regardless of the organization. Mileage may vary on all of these, but the point is that you need to have a way of understanding what success looks like.

And if you’re only measuring features built or hours spent—those don’t have any business value, so they’re hard to get excited about and don’t mean anything at the end of the day.

The Benefits of Agile in Product Organizations

Alright, we’ll admit it. We said delighting your customers was easy, but maybe it’s easier said than done. It’s going to take some planning. But it’s worth it. Here’s why.

Once you nail prioritization, begin prototyping like a boss, and have tangible business metrics to tie it back to—it’s like you’ve discovered this new hidden superpower. Suddenly, you’re stacking cash, keeping stakeholders happy, providing your teams meaningful work, and ultimately delivering products your customers crave.

And happy customers are always the number one hallmark of any successful business.