Problem Discovery for Data PMs PART 2 - Figuring out Product Roadmap for a Data Preparation Tool

How can you use Design Sprints to identify next level of opportunities as a Data PM.

Hi data enthusiasts,

We are now on the 11th edition of the Data PM Gazette, and I am proud to say that we have become a community of 150 readers (thank you 🙏)! I would love your feedback on what topics will help you more and what you have liked so far. Just respond to the email or leave a comment, a line will be super motivating :)

Without further ado, let’s dive deeper into the second case of problem discovery I wanted to talk about because the stage/type of product is very different, as well as how I approached it.

If we were to relate to the matrix that we used in PART 1, this second product falls in the Growth stage and the “Data Platform” category. So, a very different situation, and therefore, a different process.

For this substack, we will discuss what the context was, my constraints, my problem discovery and solution discovery process, and what did I right or wrong.

Case 2: A Growth product looking to unlock the next stage

Back in 2020, I was consulting other product organizations as a Partner at a product / UX studio called “Parallel” in India. One of my clients was a specialized data preparation tool that helped large pharma companies in the US manage data pipelines (what is that?) for their research work. They had found Product Market Fit (read this if you haven’t) with a basic “data ingestion” tool and had built it scalably so had good customer traction, but wanted to create a version 2.0 of the tool that becomes a permanent part of their customers’ stack i.e. more product adoption was the goal.

My Constraints

This was quite a unique situation because:

1. I was an external data product manager i.e. I had no prior customer knowledge or empathy, and I wasn’t involved in day-to-day action.

2. I had 3 months to suggest a new product strategy that could give the company the roadmap for two quarters, post my strategy work.

3. The team had no data on usage, and adoption, or any documented previous customer research.

4. We didn’t have endless resources to build the next iteration of the product. Also, the product was quite technical and had no documentation.

The firm gave us the project because of my previous domain expertise, as well as the success of a particular type of discovery process that Parallel had championed (and so did I). And, had given us a free hand to do any type of discovery we wanted.

My problem-discovery process

Given the scope and the time-boxed nature of the discovery process, we banked upon two methods that are classified as “UX methods” usually but I find super helpful for product strategy work:

1. UX audit — a simple process that studies whether the current product meets the users' needs and business goals. Learn more about the process here.

2. Design Sprint - A structured speed innovation process, typically running for a week, that takes you from “an idea/problem” to creating a solution and testing it with real users. See the full process here.

   

I can go on and on about design sprints and why they work, but here’s the TL;DR:

(a) Design Sprint gets the viewpoint of all stakeholders in a structured way, and

(b) They help you create a tangible prototype that you can test with a few real users to know whether what you are showing helps the end user or not.

And, from all enterprise standards, this is probably the fastest way of doing something like this. So, here’s how I went about this discovery:

1-week UX-audit + Internal Interviews

To get ahead of who the users are, and how the current product solves the current pain points, my team did a UX audit, and here’s the process we followed:

• In-depth product demos to understand the current workflow and document the pain points and user journey.

• Internal interviews with founders, chief technology officers, Product Managers, and Engineering Managers to understand whether the product achieves the goals or not.

• Create screen-by-screen actionable improvements that the team can work on short-run.

• Check if the product follows UX heuristics/standards well.

Output: A Product UX Audit Document that gives recommendations like this report.

Design Sprint - Fast-tracked Problem + Solution Discovery

Once we had given some direct recommendations, we moved on to the vision setting. We set the expectation that this exercise was to set the vision. So, we decided to run multiple Design Sprints to get multiple rounds of feedback from end users.

• Design Sprint 1 - The first sprint helped us set the stage. We followed the usual workshops as defined in the book Sprint, and used the following structure to define a long-term goal for the product, as well as what are we going to test in the short run and build a prototype towards it.

  

  Here’s the breakdown of different workshops, you can find all the information to run on Google Ventures’ Official Website or using AJ Smart’s guides.

  • Expert Interview workshop - Defining “How Might We” workshop to define all current challenges that various experts choose.

    

  • Goal definition workshop - Define a long-term goal for the product, as well as what the biggest fears are in achieving those goals, and test those questions through a prototype.

  • Defining a Target workshop- Defining a target i.e. using all the problems, goals, and fears, mapping a journey that we want to test with our testers.

  • Solution workshop - We did lightning demos to draw inspiration from different competitions/tools as well as created sketches to discover flows /solutions that could help us achieve our goals.

  • Storyboard workshop - What is the final story that we want to test, and see whether that elevates the product goals?

  After creating a prototype and getting feedback from users, we realized that we did get the new flow right, but the reviews were not super glowing. On further discovery, we got some more insights from internal leaders that helped us simplify the journey and bring in some much-needed improvements. So, we created another prototype that addressed the confusion of the prototype and had a clearer direction for a data prep tool.

• Design Sprint Round 2 - Created another improved prototype with feedback from the first round and with a better user workflow to see whether users prefer the direction we are headed in.

At the end of these two processes, we got validation for our initial ideas and a product direction that the team can comfortably move forward with. And, we then worked with the Engineer team to flesh out specific aspects of the Product Roadmap in the short run.

So, did it work?

Yes, and no. Yes, in terms of getting onboarded and nailing down the project. No, because we got a few of our stakeholders wrong. But, as a team, we were able to come down to a meaty product direction that we can confidently build upon.

What did I do right?

1. I couldn’t have gotten a head start on understanding a technical tool without any concrete documentation if we had not opted for Design Sprint and UX Audit as our method of discovery.

2. I had a good sync with the internal product manager to understand how things are moving. Communicating almost every day was key.

3. As part of the discovery, we did get in front of end users and understood whether pain points were real or not.

4. Being an external PM, I wasn’t tied to the problem or solution and so it helped us to pivot quickly, as we got more input from the team.

5. We did burst people’s myths about their products and users because even though we were external, we were the only ones who had asked discovery questions.

What did I not do right?

1. I missed including a founder in the process (because of schedules), and realized only late, that his thoughts were very important, so that was a big miss. Getting the stakeholder right is important, especially if you are crunched for time.

2. We didn’t dig deeper into the current roadmap, because we were told that we needed to provide a fresh perspective, but always seeing what the company has thought about would have been great.

3. We didn’t speak to the architects enough, so some of our suggestions wouldn’t have made sense from an architectural perspective.

How can you use this process?

While you might not do a full-fledged design sprint, you can take the principles of a Design Sprint to explore and test new ideas confidently.

1. Get all relevant stakeholders in a room and run a process to do problem discovery.

2. Don’t do meetings instead run workshops with a solid goal that leads us to discover problems better.

3. Create visual prototypes and test them with real users to see if they will solve the problem.

4. Go back to the drawing board and re-define the user journey, or simplify a journey, and iterate until users get excited.

🔗 Links of the week

1. So,

   Benn Stancil
   started talking about “Category Collapse” in the data tools (also called “Modern Data Stack”) landscape and pointed to more consolidation for observability/catalog categories. And, this week, Collibra just expanded its footprint by buying a data notebook startup.

2. Lenny Rachitsky
   ’s analysis of the B2B market is timely to achieve Product Market Fit. He compresses his learning across multiple B2B companies in a simple graph - and is probably one of the kind resources available in the market. MUST READ!

   

3. Writing a PRD around LLM Observability? This article found in

   Data Machina
   might help.

Signing off,

Richa,
Chief Data Obssessor, The Data PM Gazette