Product Management Skills - Articulating assumptions and acting with intention
If you aren't intentional about what you do and why, your outcomes will be driven entirely by luck, and you will never be able to self-improve.
Product Managers are responsible for proposing informed changes to products. They propose these changes to drive towards an outcome that is hopefully beneficial to the company.
I have worked with many Product Managers who made decisions, but lacked intentionality. Their proposals were arbitrary and seemingly random. They often didn’t have the desired effect, or caused significant issues.
A lot of this came down from the fact that they did not know what they were doing - quite literally. They didn’t take the time to truly think about what they were attempting to do, and therefore wasted significant time and effort of teams of developers.
When they did have wins, it often amounted to sheer luck due to some outcome or interaction they didn’t even think about. Sometimes progress was made in spite of their contribution, thanks to the hard work by the team to fill gaps.
What they were doing wasn’t product management, it was product gambling.
The best product managers I’ve worked with had intent behind every decision they made. Right or wrong, they could articulate and trace their thinking through some logical path, effectively identify their assumptions, perform validations to de-risk their plans, and rapidly incorporate feedback to self-correct.
It doesn’t mean they were always right - product management is a job of probabilities, not certainty. However, they were right more and more often as time went on, and even when they were wrong - they could course-correct to be eventually right. As a result, their wins compounded and their losses had minimal negative impact.
The Intent behind Product Management
To be intentional, you need to at least know your train of thought that led to the conclusion you had. When you develop a proposal to change the product, you should be able to articulate the train of thought, and take people along that journey.
Discover and define your problem space
Define and propose an approach
Form a hypothesis
Articulate your assumptions
Validate your assumptions
Decide and act
Monitor results and outcomes
Note: if your process is “make proposal → see results”, then you’re just throwing spaghetti at the wall. Any random monkey can do that - that doesn’t add value to the team.
Discover and define the problem space
Discovery can have a lot of different sources - from feedback to user interviews to hunches - you become aware of the existence of a problem.
Once you have a general awareness - you want to define it.
You can do that by first articulating the theoretical framework for how your problem space ladders into your company-level goals. This problem space might ladder up into a variety of other spaces that ultimately feed into your bottom line - typically revenue or some other business consideration.
An example
Suppose you have a hunch that users aren’t using the search bar.
You might’ve heard an off-hand comment, or maybe you saw a bit of a strange delay from watching a new user navigate the system. Perhaps you overheard a support agent talk about some convoluted filtering a user is doing that is more complicated than searching, and that set off your product instincts. Maybe you saw unexpectedly low usage in analytics.
Whatever the cause of the hunch, you now have a problem space - users not searching.
The next step - you can ladder up this problem space into a higher-level goal:
users not leveraging searching → opportunity to improve user efficiency → improve user time share spent on impactful events vs. non-impactful events → increase rate of impactful events which drive business outcomes → if impactful event is monetized, revenue
You don’t need any numbers right now - you just want to develop a theoretical understanding of how this area might contribute to your company’s goals and objectives.
Define and propose an approach
Once you understand the ladder, you can define and propose an approach.
Your approach proposal isn’t the definition of the solution itself, it’s a proposed way to solve, in part or whole, the problem space you are exploring.
Your proposal might be “I want to improve the visibility of the search bar to address the problem of users lacking search awareness” or it might be “I want to do a training video on making sure users know how to use the search bar”.
Both can address the problem of users not leveraging search.
Note: a key callout here - there may be many different ways to solve the problem - from product changes to marketing pushes to communication adjustments - don’t get stuck in a “Product is the solution” box.
Form a hypothesis
With the theoretical chain of how the problem space or solution creates an impact, you can now form a hypothesis.
Your hypothesis should be simple - describable in three simple sentences.
A hypothesis is an assertion of what you believe will happen given an action you take.
Your hypothesis could be:
By improving visibility of the search bar, we will be able to increase awareness, and thus increase usage of search functionality, replacing time-consuming behavior of manual filtering and paging.
We project this will improve the number of impactful events by 3 / day / user by freeing up time otherwise spent on non-impactful events.
At a monetization of $25 / impactful event, this is estimated to have an impact of $25 / day / user, or $25,000 / day across our 1,000 users.
If you can’t describe your hypothesis in 3 sentences, you likely haven’t defined it well enough.
Your hypothesis should have:
What you intend to do or solve
How it relates to larger goals
What the expected impact of it is
Don’t have a solution, or work in an organization where solution ideation happens downstream? That’s fine too - you can start at the value of the problem.
Articulate your assumptions
Once you have your hypothesis, you can start to point out any expectations and assumptions you have made in creating that hypothesis.
An assumption is a belief that you have that isn’t proven by any data, that you are basing other decisions on or that has an interaction with your problem space that changes the feasibility or ROI proposition (return on investment).
For the above example, you might list your assumptions and expectations as:
Users aren’t using the search bar.
Are they actually not using it? How do you know?
They don’t know it exists.
Why do you think they don’t know it exists?
Making the search bar more visible will increase usage.
Do you actually know that’s why the search bar isn’t being used today? Could it be another reason?
Users will spend any time not spent manually filtering with doing impactful events.
Why do you believe the time will immediately go to impactful events? Would it go to getting a cup of coffee instead?
This time spent will translate into 3 impactful events / day / user.
Why do you think time is the limiting factor of adding 3 impactful events? Could there be other factors?
The monetization rate of an impactful event is $25 / day / user.
Why do you think the monetization rate of an impactful event is the same as others?
You can sustain the monetization rate of an impactful event.
Do you think there might be a chance of diminishing returns?
100% of the user base is suffering from this problem.
Why do you think 100% of the user base is suffering? Could it be 50%? Is it still worth it at 10%?
Listing these assumptions and asking yourself why you believe these to be true is extremely valuable to pressure-test your theories before investing further time into them. By listing the dots, you can validate that you are connecting them logically.
Assumptions are expectations that you haven’t validated. Technically, every expectation is an assumption before anything is given to users. Some of the above examples, like $25 / day / user, may have already been validated by others, or may have obvious answers (eg. “we have a contract”) but the explicit callout is useful.
Anything you haven’t quantified can also be an assumption. If you are’t quite sure the number of impact events per day per user it might be worth validating just to shore up your ROI calculation.
Ask yourself questions
Having trouble figuring out what your assumptions are? Fear not - it breaks down into asking yourself two simple questions:
What are you expecting, and why do you expect that?
Are you expecting your users to do anything? Why do you believe they well?
Are you expecting your users to change their behavior? Why do you believe they will?
Are you expecting a specific amount of impact or change? Why do you believe it will?
Are you expecting a particular size of users or customers to be impacted? Why do you believe it will?
Are you expecting to address a cause to a particular problem? Why do you believe that is the cause?
You can also categorize assumptions, and verify that you’ve covered each area with at least one factor:
Assumptions about user behavior
Assumptions about sustaining or improving trends
Assumptions about the actual cause of the problem
Assumptions about the scope or reach of the problem
Assumptions about the customer
Assumptions about the value
Validate your assumptions
Once you have your assumptions, you should validate them. Validation means proving or disproving the premise of your theories.
The point of validation is to reduce time spent working on the wrong thing. If you’re able to invalidate an assumption early, you don’t have to incur the cost of developing a solution because you’ve already determined it won’t work. If you validate all of your assumptions and they hold, you likely have a solid path forward to value and impact.
Start with your core assumptions. Some assumptions are not core to your problem. That is, if they don’t hold, your general premise might take a hit, but still holds.
For the above example, if you had assumed 100% of the user base was suffering from this problem, and it turns out only 75% was, your solution may still have an impact - it just won’t be the same magnitude as initially expected. That’s not a core assumption - it just impacts the expected ROI.
However, let’s say you had assumed users weren’t using the search bar because it wasn’t visible, but it turns out it was because they want to search using something that your search doesn’t search by. In this case, your fundamental assumption is flawed - your efforts to improve awareness of search will have no impact.
If you don’t have the data to test an assumption, get the data. Whether that’s analyzing existing data, implementing additional instrumentation, making a small change to test a specific assumption, performing additional customer or user interviews, or creating a paper prototype an sharing it with customers - there’s dozens of tools available to you. Use this data to inform your assumption.
At that point, you’ve disproven your theory and hypothesis and unless there’s another compelling reason, your solution likely won’t solve their problem.
Decide and act
Go through this process a few times and you’ll have set of problems, possible approaches, and opportunities.
At this point - you can stack rank, prioritize, and apply various frameworks or factor tradeoffs to make a decision and act.
Prioritization is a nuanced skill, highly dependent on your context. Whether you use something as simple as Eisenhower framework (urgent/important) or more complex like RICE - you should be able to take these opportunities and stack rank them to identify high value ones to act on.
Once you decide - make sure your team understands all this thinking that occurred, and ensure you effectively define the problem and the solution space, and manage the stakeholders, shepherd the go-to-market approach, and any other activities that are necessary to successfully release your proposal to users.
Monitor results and outcomes
This is a key part of post-action. One you and the team actually implement your approach, be sure you watch the results. Look at analytics, do additional post-release interviews, check in with your users and customers.
If you assumptions held and it had the impact. you expected - great! If not, use those. to learn and adjust. Did you encounter an unexpected result? Did it have more or less success than you envisioned? Was your central premise valid?
All of these things should be factored into the next decision you make and. the next action you take.
The key, once again, is intentionality. Think through things and have the follow through after release to incorporate the learnings.
If the spaghetti stuck to the wall - why? If the spaghetti fell off the wall - why? If someone came by and ate the spaghetti - why?
Keep reading with a 7-day free trial
Subscribe to Joseph Gefroh to keep reading this post and get 7 days of free access to the full post archives.