This is Step 4 of “4 Steps to Develop a Strategy”, focused on finding power users who have already been compelled to find some solution to a need they have. Can we productize some version of it to serve other users while addressing the buyer’s pain point in the same product?
 |
 |
There’s a difference between a strategy and a product definition. This step is not about building a product (that has to be an iterative process with actual users over time), but rather about defining the few pillars of the product that put both a direction and guardrails on your product development.
Why do we need Step 4 at all? Isn’t it enough to have identified a value pool?
Whatever value pool you identify, you should be aware that the market will be flooded with companies claiming to solve it. You can differentiate based on ROI case studies (when you get them) and a focus on a unique root cause … but more valuably, based on a focus on a unique user and a unique way of serving that user. Win over the user and the buyer will follow.
Software as a Service (SaaS) companies are realizing that contract renewals are determined in the first few weeks of deployment: if users are engaged and adopt quickly, renewals two or three years later are already on a strong path.
While delighting your users won’t fully be solved in your strategy, the rough guideline for accomplishing it has to start with the strategy. A focus on the buyer is not enough. We now turn to the user.
(4a) Identify our users. Our buyers are not our users.
My colleagues and I kicked off our most recent startup about 18 months ago. We knew our “buyers” very well, having served Chief Nursing Officers in hospitals for many years. We scoped out and pitched a product to them that we believed would solve one of their most pressing needs, the need to engage and retain their clinical workforce.
We also knew our “users”: nurse managers in those hospitals. We knew that nurse managers had a very difficult role and designed a product approach based on dozens of hours of discussion and feedback with those managers, as any good Lean Startup would do.
We also knew that buyers wouldn’t buy our product if they didn’t truly believe that the users would use it, so there was natural alignment there. But what I have consistently been surprised by in the course of the past months is how different the two stakeholders’ needs are and how difficult it is to be a startup that is trying to thread the needle between them both.
A large number of our product and strategy discussions have been around what to build, how to organize what we are building, and how to message it. In so many discussions, the question has come down to: should we build for (and message to) the buyer or the user? And if we want to balance both, how do we best do it? Which one matters more for sales? For product adoption? For impact?
I don’t profess to have a perfect generalizable solution to the challenge. I simply raise the distinction because realizing that we had multiple stakeholders and part of the magic of our product is to unite them both has helped us.
Terms like “Product-Market Fit” are ubiquitous and are a good example that we often don’t disentangle buyers and users.
In our startup, we evaluate our “Product-Buyer Fit” and “Product-User Fit” separately, for example.
Buyers are not users… even when they’re the same person.
If they are the same person, they are still different stakeholders. Too often, strategists merge buyers and users into “customer” and they lose insight because of it. Buyers and users have different goals and pain points.
For example, how many times have you (as a buyer) bought a plane ticket and chosen the cheapest one? Then weeks later when you (as a user) are waiting in long lines, sitting in a cramped middle seat, and suffering through delays and cancellations… and cursing the earlier version of yourself for being such a cheapskate?
When you are serving the user, delight them with what they care about (e.g. how easy your product is to use); that’s a great way to have them buy from you again. But don’t distract the buyer with messages about what only the user values.
(4b) Determine the two to five unique and pivotal decisions that will define our solution—and will delight our users
Our chosen method for addressing the value pool is only the start. Here we need to weave in the user. How can we delight them while impacting the buyer’s value pool? How will we create raving fans?
These have to be directly connected to our sources of advantage as well. In Southwest Airlines’ case study, for example, their value pool and source of advantage focused them on serving short distance travelers from smaller, more suburban airports. Therefore, it would have been out of synch for them to choose first-class dining or multiple business class seating hierarchies in how they served their user. From their value pool and source of advantage, you can clearly draw a direct path to being a lower cost and more agile company across the board.
Our goal is to develop the two to five unique and pivotal decisions that define our solution. Determining what they are is perhaps the hardest part of developing a strategy. Often, when starting on a new product, you don’t know, because it requires a working knowledge of the user and what they value. But it’s important to build a perspective and evolve it.
These decisions will allow us to best serve our chosen buyers and users, leverage our sources of advantage, and align us with the larger trends.
These decisions should be internally consistent and mutually-reinforcing.
For example, with a company I was a part of, we believed that generating insights from a particular data source would be one of the core product attributes that would define our solution. Over time, we discovered that component of our product wasn’t as important to our users—so we demoted it and promoted other decisions. So, while all Four Steps of a strategy are connected and will evolve, this section needs a strawman that gets re-evaluated often, especially in the early days.
Interviews are still a valuable tool
We need to talk to potential users about what product would be valuable for them, centered on the chosen method. Resist the urge to jump into a specific product solution. And resist the urge to frame the problem in terms of the buyers. If we go to nurses and say, “your CEO wants to accomplish this and here’s a product we’re working on that can help do that”, the odds are they will say, “Great! Another thing for me to do that’s pushed on me by the administration! Don’t they understand how busy I am and how I have no time to do every new thing they come up with?”
What you have to do is talk to the users about their needs and areas of friction and build your product and story to them around where they are.
You need to accomplish a job the user is already trying to solve
Let me be clear: no user will use your product unless it helps them solve a problem or accomplish a critical job they are trying to solve (even if it solves a buyer’s problem and the buyer is their boss). To get product usage, you need a user’s internal triggers to fire and then you want to be the reaction they have to that trigger firing. You cannot create usage by giving people a product and saying it does something new that they are not trying to do. Amazon on a cellphone does this for many people: whenever they think they need to buy something, it’s easier to open their phone and buy it than it is to write it down on a shopping list and buy it later in a store. The internal trigger fires and Amazon is the brain’s go to response.
Don’t build two loosely joined products here—one that solves the buyer’s need and another for the user. Focus on doing one thing well. The magic is threading the needle between the users’ and the buyers’ needs.
Find the “power users” out there and ask them what solutions they have cobbled together for themselves. Then productize that.
Power users are the most forward-thinking of your user base. They are often the most tech savvy, may have multiple cross-disciplinary degrees, and/or may have worked in another industry. Use LinkedIn to find people who meet that profile and interview them.
Look at what they’ve built themselves. If users have a real need, they’re not going to sit still while waiting for someone else to solve it.
The odds are that users are not immediately solving a problem aligned with a buyers’ value pool. But aligning them to win over both in a single product is where you should focus your efforts.
Find the smallest prototype of the product/solution that will fit both buyer and users’ needs
This is often called the “Minimal Viable Product” (MVP) in the lean startup vernacular. I prefer the term “prototype”; MVP includes the word “product” which already plants the idea that it has to be something real. Prototype, on the other hand, conjures the right image for me: something duct-taped together in an afternoon. It doesn’t matter how rudimentary or unscalable it is. Its goal is to help you learn about what your buyers and users need and want.
If yours is an analytics company, could you imagine some early, viable version of the solution being built in Microsoft Excel? You might not actually build it that way, but if you can imagine it, you can then imagine how you could build a working version of your product in six months. On the flip side, do you need massive data to get started, which you don’t have? Or do you need to invent something that doesn’t exist today just to get started? If the latter, that would be a warning flag for me.
. . .
This article is an abridged chapter from a book of mine, 4 Steps to Develop a Strategy