For those left hanging since July, it might help to quickly review Part 1 first.

Got your I-curiosity primed? Great! Now, let’s dig into the scientific method in product management. I’ve modified an interview question by using a fictional company “NovaRE” but retained the situations you’re likely to face as a Product Manager, including the inherent ambiguity embedded in the task. Here’s the situation:

“You now lead the NovaRE digital suite for real-estate and discover that one of the commercial real estate portals is getting little traction. This is an app that shows buyers office-space for sale and has advanced search capabilities by features and zip code. One product manager on your team thinks we should re-design the app with GenAI because it is too complicated to use. An account manager thinks we need better filtering for clients. The NovaRE VP, who owns the app says you can’t kill it. However, you have been tasked with growing the digital suite revenue by 100% over the next year and this app is not contributing to that success.”

If you interviewed at FAANG or are already there, you might jump to your favorite framework to start chalking out a response. There are a ton of videos and articles on frameworks, but we’re talking about one of the oldest frameworks in modern history — the Scientific Method — and applying it to Product Management. I came up with this approach a few years ago to coach my team in handling real problems and not just interviews.

The framework: Observation & Research → Hypotheses → Testing & Action

This structure is no different from what Aristotle or Galileo might have used for structured thinking and hypothesis development in philosophy and the natural sciences. It fits extremely well with Product Management.

Observation, Validation and Research

The first step would be to clarify the meaning of “traction.” Is it site visits? Are site visits the right indicator for sales conversion? If not, what is? Are all transactions through the portal or are there account managers for each region with the portal only serving as an internal sales channel? What are the sales trends for the past few years? Are there any anomalies? How do these metrics compare with other applications in the digital suite? Are there external factors influencing traction? What could they be?

Establish the metrics that support the observation before proceeding.

If preliminary research and data support the observation, it is time to start digging into more data and have conversations with a variety of internal and external stakeholders. Examples of quantitative and qualitative research:

  • Client data, trends and views across zip-codes, age-groups, gender and other discriminants, to narrow down if the traction is slow universally or exhibits a pattern
  • Conversations with sales, marketing, account teams, customers, architects, engineers, other product managers and executive leadership

Hypotheses

This is the fun part. You’ve got the results from initial research, data and a ton of validation. So, what would you think are the reasons for low traction? Remember each hypothesis will need to be tested and it’s critical that the hypothesis bear some correlation to the observations and research so far.

Technical: Are there technology limitations in the stack running the portal? Is the UX and flow based on customer research?

Segment: What does the research say about segments most likely to use the portal? Was there validation of Product-Market fit? Is this the right segment for this product? Does the target segment prefer using a conversational interface?

Positioning: Are we conveying the right value-prop to our clients? Is there a clear message on outcomes and client ROI? Have we trained account teams and sellers accordingly? Does the portal experience really solve for key pain points?

Competitive: What other options do clients have? How and why is our portal better? Are we competing on price, quality or benefits in the overall digital suite?

Pricing: Are sellers or clients complaining about price? Why? Is there an anomaly when compared with other products in the digital suite?

Ecosystem: Does the portal work best standalone or integrated into the digital suite? What are the tradeoffs?

Incentives: Are seller incentives aligned with promoting this product along with everything else in the suite?

Support: How responsive and thorough are we on support? What does the data say?

Testing and Action

Team members have pointed to a few flaws and their own hypothesis. Trying to solve some clients’ frustration with the UI might not mean that a GenAI based interface is the answer. What if the segment generating the most revenue doesn’t want a conversational interface? Some hypotheses are easier to test; for example, it is considerably cheaper to improve the filtering algorithm on the portal than to completely redesign it as a conversational interface. Where practical, simple and agile tests must be run to vet the hypothesis. If there’s a problem in positioning the value of the portal, there might be an easier fix with the right messaging.

The testing phase must involve going back to stakeholders to vet the hypothesis and determine the right course of action.

I think more product managers should get trained in the scientific method than rush to get an MBA. Being able to grow your curiosity chops is key. The scientific method helps build your I-curiosity and has universal applicability to most situations where you’ll find yourself juggling emotions and data.

Rabbit Holes

I would revisit Part 1, especially Neil deGrasse Tyson’s note on intellectual laziness and the psychology of curiosity. The interplay between structured thinking and emotional intelligence is what makes this approach applicable well beyond product management.