The first major milestone delivery just passed on one of my projects. The delivery was on time and the client was happy with the functionality. But, candidly, the product direction we received from the client throughout that milestone was choppy and disjointed, at best.
We started the milestone with a list of user stories that the product stakeholder gave us. Some of these stories had proposed solutions already attached to them. Once our design team started digging into these stories, we quickly discovered that they were not validated by users. In effect, we were being asked to implement one stakeholder’s ideas.
At Atomic, we advocate for sufficient time at the start of a project to learn about users’ needs, tasks, and workflows. We’ve written a lot about the benefits of user research and how we execute our own Research, Design, & Planning (RDP) Phase. Unfortunately, the reality of building software is that sometimes there is little-to-no time budgeted for discovery or user research.
Projects that can’t “afford” to spend time in the RDP phase can still try to channel the user in the design and delivery phases. They can do that by adopting a hypothesis mindset throughout the product lifecycle.
I’ve been thinking about how my team can improve its chances of building the right features when we can’t rely on user research. We need to adopt a hypothesis mindset on this project.
What is a hypothesis?
A hypothesis is a testable answer to a particular question. In science class, most of us had a lesson or two about forming hypothesis statements. A simple lesson that I remember from entering a science fair in sixth grade was to follow this format when creating one: “If ___ then ___”.
On product development teams, a hypothesis is often expressed as an “I think” or “I bet you” statement. These statements are beliefs based on what the product owner knows about her industry and customers. For example, “I bet you that if we alert our user to a price reduction, then she will purchase the (insert name of the thing).”
What’s critically important about using hypotheses in product development is the emphasis on testing the statements.
Why do we need a hypothesis mindset?
- Ideas are plentiful.
- Ideas are full of bias and optimism.
This is the first in a series of posts about the importance of using hypotheses in product development. Here’s what I’ve observed when product teams don’t think in terms of testing their belief statements:
- Assumptions take over, allowing a stakeholder to presume a solution.
- Teams waste time on developing features that don’t get used.
- They blow through the budget before completing critical path features.
- They lack sufficient data to back decisions.
In future posts, I’ll expand on each of these observations.