It’s pretty obvious but I’ll say it out loud – the more we understand about a problem, the more likely it is we’ll make better decisions about how to solve it. The law of diminishing returns applies here, of course, so we can’t spend an infinite amount of time trying to understand everything. Because every problem is different, there is no cookie-cutter approach to understanding every problem, either. What any good researcher will do when confronted with a problem is draw on their extensive toolkit to find the right tool for the right job. At Cogent, here are some of the activities that we typically run and give us the best bang for back, whether a business is a startup, in rapid growth, or scaling quickly:
- Knowledge-gathering conversations with key stakeholders in the business
- User research and analysis to understand what users are currently doing and why
- Workshops to flesh out objectives into tangible useful data to guide the strategy
- Business process mapping in priority areas
- Distill thinking into conceptual sketches
- User testing or technical exploration of potential approaches
- Modelling and forecasting to understand the commercial opportunity
- Workshops to define main breakdown of delivery
What size of problem are we dealing with?
When we’re diving head first into a problem, the first step is to understand the risk associated with solving it poorly. One thing I’ve found helpful is to characterise a problem as either a boulder, stone, or pebble. To do this, we need to assess each problem against the 4 risks of discovery:
- Value risk. Will customers buy it or users choose to use it?
- Usability risk. Can users figure out how to use it?
- Feasibility risk. Can our engineers build what we need with the time, skills, and technology that we have?
- Business viability risk. Will the solution work for other various aspects of our business?
The depth and time required to clarify these risks will normally indicate to us what we’re dealing with. Once we know whether we’ve got a boulder, pebble, or stone on our hands, we’re able to plan a discovery accordingly and, importantly, provide certainty around timelines which lead to certainty to roadmaps and shipping value.
Matt working through some potential Boulders, Stones and Pebbles in the Cogent office.
Boulders (Approx 5 weeks)
Boulders typically have a lot of uncertainty. That’s what makes them boulders. We may be uncertain about the user experience, the technical complexity or the commercial opportunity. Either way, it’s a chunky piece of work that needs a Designer, Product Manager, and Developer working on reducing the uncertainty, together, over about 5 weeks.
The goal of a Boulder discovery is to answer, fully or at least with enough confidence, the 4 risks above.
A sample agenda of how it can be done:
Week 1: Kick-Off and shaping the goals
- Kick-off, shared-understanding, trade-off sliders and guiding principles
- User research: Process and Workflow mapping
- Product research: Market research, competitor analysis
- Onboarding developers to new domain if required
Week 2: Research synthesis and gaining shared understanding of the customer problem
- Draft Customer Journey Map that describes the ideal workflow
- Confirm/Validate Customer profiles who are core to the work
- Technical Gap Analysis: Begin getting a sense of what we can do now versus what we’re likely to need to do to deliver this work
Week 3: Potential Solutions start taking shape
- Prioritised list of high-value jobs-to-be-done and painpoints
- High-level effort against value
- Developing Now/Next/Later plan
- Development of tech strategy begins
- Detailed concept development
Week 4: Refine solutions, roadmap and tech approach
- Breakdown of requirements and more detailed concept sketches
- Finalise Now/Next/Later based on user feedback
- Refine technology approach
Week 5: Validate
- Validate concepts/assumptions
- Estimates for first pieces of work (the Now’s)
- Complete Now/Next with good clarity, firmer view of Later
- Tech Strategy complete
Stones (approx 2-3 weeks)
In comparison to boulders, stones have less uncertainty and risk. This often means we know a bit more about one or more of the value risk, usability risk, feasibility risk, or business viability risk.
The plan to deal with stones should be similar in process, but it should take about half the time because much of the knowledge to assess the risks should lie within the team.
- Value risk. A stone is normally something we’ve heard about already, either from the people within the team, or prior user research. We know it’s a pain point and it comes up relatively often.
- Usability and Feasibility risk. A stone’s size normally involves usability validation because there are often multiple ways that we could solve a stone-sized problem for a customer. Because of this, it typically requires a runway of 2 weeks for a designer. The first week is spent running concept-creation workshops alongside an engineer and product manager to arrive at a couple of concepts that are feasible. The second week is to test or validate those concepts with some users to get a signal on which concept will solve the problem more appropriately.
- Business viability risk. Typically stones won’t have a huge business viability risk but there may be some advantages to one solution over an another that may benefit the broader business and so the product manager should set aside some time to shadow and understand the discovery progress of a stone.
Don’t let the size of the post-it notes fool you, Scott is working through some Boulders in this picture.
Pebbles (less than a week)
Pebbles are characterised by very low risk and uncertainty. Because of this, we rely on ‘best-practice’ or ‘common-practice’ principles to solve the problem rather than needing to investigate for any length of time with users. For a pebble, there should be:
- Little to No value risk. If there is, you’re probably dealing with at least a Stone.
- No ambiguity in the way to address the problem in terms of usability or technical feasibility. i.e There should be a single, clear, easy fix. If it’s not immediately clear, it’s likely that you’re dealing with a Stone, and not a Pebble.
- There should be no business viability risk to consider for a Pebble.
A common language
Using the Boulder, Stone, Pebble analogy for understanding the size and risk of a problem gives the working team a common language for understanding what is usually a difficult, messy thing to articulate. I’ve seen this work exceedingly well in new and established teams. It helps with planning and road-mapping, setting clear expectations for everyone in the organisation (whether they’re C-Suite or within delivery teams) on the time and cross-disciplinary effort it’s going to take to reduce the risk in moulding a product and growing or scaling a business. In the end, everyone benefits.