Viability: strategy, user and problem

This is a 5-part mini-series (with a bonus Part 0 on desirability) on my experience building AI/ML and data products over the past decade. If you have not read Part 0 (desirability), it would be worth going back to read that first here, as these things do have some order to them. Restating here that some may find what I say here to be agreeable, others heretical; however, I hope all of you do find some value in applying these principles in your own product development journey. Whatever your take, I’d love to hear your feedback and comments.

Now you have observed evidence that your product could be a means to get someone to a desired future state — great! Before we start thinking about any technical aspects of the product (data, models, etc.) we need to ensure that we are solving the right problem, and that this problem is worth solving. This is still part of discovery, and constitutes the “business understanding” phase of the CRISP-DM framework, covering both the “empathize” and “define” phases of the design thinking process.

Understand the strategy

Company strategy

It is helpful to know the industry you are building the product in, as well as your company’s positioning. What is the company’s competitive strategy? There are two basic types of competitive advantages: low cost and differentiation, and three genetic strategies for achieving above average performance in an industry: cost leadership, differentiation, and focus (cost focus or differentiation focus). This comes from Michael Porter’s book, Competitive Advantage (1985); but this a good article for a general overview.

Moat

As a product manager building AI/ML products, it is critical for you to understand the moat of your company and/or product. Of course, in the world of AI, the holy grail of all moats is the data moat. Short of that, perhaps a technology moat — which is easy to claim, hard to prove, and harder to keep in an increasingly open source world. Or if you are in industries such as healthcare or technology, a distribution moat which favours incumbents to newcomers. And of course there are those that apply almost universally across industries — switching cost, brand, network effect, cost, scale. It is wise to pay attention to which of these apply to your company, and which of these your product could (potentially) create for your company.

How to go about understanding the strategy really depends on what you have available at your disposal — you could read up on your industry, look up and read about your competitors, go through publicly available documents such as quarterly or annual reports, or analyse internal documents such as strategy or roadmap documents. You could also speak to folks in and out of your company, preferably senior leadership — who can provide an indication of the criticality of the problem area you are trying to address through your AI/ML product. If you have any quantitative data at your disposal, analyse it to understand trends and get a sense of where the gaps are that you can address. It is always a good idea to look at the macro trends in the industry and put what you have learnt from your company research in its context. This helps calibrate the magnitude and direction of the opportunity you are seeking to address. Aligning with these macro trends, understanding what shifts are happening across the industry, and why your specific solution makes sense now are all important if you want your product to live long and be widely adopted.

Understand the user

Now that you have a clear understanding of how critical the problem space you are addressing is for your company, it is time to get to know those for whom you will be building your product — the users. There are various ways to know your users — the best of which are direct observation and interviews. Observing your users in their “natural habitat”, i.e. shadowing them at their normal routine is helpful because you pick up on things that they may not articulate when speaking with you. This also helps you map out their current work process (user journeys, process maps, service blueprints). By directly talking to your users you will have a much deeper understanding of their desires, of their current and future states, their pains and struggles. Of course there are many ways to capture this (building empathy maps, user personas). The three questions you want to have at the back of your mind are what (what do you see/observe), how (how are they doing the job — are they struggling, frustrated, happy, excited), and why (why do you think they are doing what they are doing — these are assumptions).

The goal is to identify a primary user who will be the direct beneficiary of your product — it will help them achieve their desire. You may need to iterate on this a few times to really nail this. It would not hurt to identify a set of secondary target users as well — those who will need to be considered when designing the product — but will not be directly using your product. For example, if your product is a patient-facing chatbot, you may want to think about how engaging clinicians to educate their patients about your chatbot may increase adoption.

Understand the problem

You have the user defined and segmented. From your observations, interview notes, and other data analysis, you should have the problem identified as well. The task here is to clearly define this into a problem statement. The problem statement needs to be broad enough for creative freedom, but narrow enough to produce a tangible solution. There are various templates online on how to generate good problem statements. I like the “How Might We” format because it is easy to answer — and therefore leads to the solution step more intuitively. For example, “how might we make drug recommendations in our chatbot more accurate”? Another format I like because of the level of detail it presents is “who, what, where, why”. For example, “new pharmacists want to get to drug recommendations but they are dropping off at the current step because we require them to manually input gene panel details”.

Understanding the strategy, the user, and the problem is an iterative process — each new information you get could tweak your understanding slightly, and the problem statement that you build as a result of this will likely evolve during your discovery period as well. And that is okay. When you feel like you have landed on a “good enough” problem statement that is worthwhile enough, that matters enough to your company, that is a pain enough for your identified target users — it is time to move on to designing the solution. It is important to get clarity during this step, of course — but it is equally important to not fall into analysis paralysis.

The next post (Part 1b) will focus on whether the problem you are about to solve is in fact an AI/ML problem — or it would be much better solved using other methods.

♻️ If you like what I write, please reshare with your network.

I just wrote the first piece of a series I am working on to help those building AI/ML products — enjoy!

---

Originally published on Medium.