keekerdcNobody wants your product.
Your customers, whether they be average people, or especially other businesses, would rather have nothing to do with you.
They don't actually want to have your product. They don't want to buy it, it's money they'd rather have for other things, like their own bottom line, or, I dunno, food.
They don't want to spend time learning how to use your product, that's time better spent on their own business, or their Game of Thrones fan-fiction rewrite of the final season.
They don't want the hassle of actually using it, at all, let alone to be "living in it" as some expect. The cost of your product to a client is not just what you invoice, it's also the time they spend mucking about with your stupid app. And the time they spend mucking about with you when it doesn't work.
What's wanted is the outcome your product provides or enables, your service is a means to that end. They pay for the result your product enables, whether that be time saved, or effort saved, or some information or materials or capability they can't get through some other means. I think teams tend to begin failing at which point the team considers the set of features that comprise the product, and the outcome produced, to be interchangeable.
Don't get me wrong, I don't think this is a particularly new or original thought. The notion of 'outcome-driven innovation' or 'jobs-to-be-done' product management has been around since the turn of the millennium, despite it not getting terribly much traction. But I'm using it as the starting point for this reboot of my blog, because I've found this concept describes perfectly the inflection point in the mentality between product teams I've seen succeed, and those that struggle and fail.
Stacks and stacks have been written on the topic of effective product management that focus on how to wrangle engineers to most efficiently do your bidding, or on estimating and prioritizing and building roadmaps, or on how to work with designers, or how to get everyone into an 'agile' workflow. All of that stuff is made easier or immediately falls into place when the outcome to be produced for your customer is clearly defined and is continually foundational to the decision making process around a product's development.
So much emphasis has been put on that initial dash to a 'minimally viable product' that it's almost as though nobody is really sure of what to do once a team has delivered that initial bundle of features. It's laughably easy to run through those first few 'sprints' towards an MVP without defining what the outcomes for customers are supposed to be.
So you've shipped v1 and done some marketing and you have some clients. Great! Now what? How about an ambitious goal, like 5x revenue before year's end? How about a sessions per user per day KPI? Time to knuckle down and start burning through that backlog, right? What's next on that roadmap you put together months ago? What's the low hanging fruit? Sales says this important client wants [some nebulous thing] that would really make them happy.
Whoops, nope, you've already derailed. And the worst bit about it is that it'll take months, quarters, maybe even a year before it's clear that the train left the tracks.
What are the customer outcomes we aim to deliver or enable?
How far are we from delivering those outcomes?
How does this proposed set of work get us closer to delivering an outcome perfectly?
These are the questions that winning teams ask themselves every week. Because your customers would rather have nothing to do with you.