The shift from inside-out to outside-in is necessary to become more effective as a product development organization. We cannot build it and (expect) they will come. Here’s how to think about shifting from simply creating outputs to actually solving problems.
Intuition is the Key
I love this quote from Gary Klein
Intuition has to be used throughout the analysis: in recognizing the problem, in decomposing it, in setting up the rating scales, in assigning the numerical values, in estimating probabilities. We cannot perform analysis without relying on intuition.
We use our intuition to develop a mapping of ‘improved capability’ to ‘increased satisfaction’ for our customers.
We start with an inside-out, (arguably) objective view of what “better” looks like. Typically, teams make the mistake of equating “more” with “better.” It is a consequence of being the experts, and building products not because our customers would see them as better, but because we would.
When teams are output oriented, they identify a set of features which they plan to deliver. This is an inside-out orientation to doing work. It is easy to feel in control, and declare success because “we finished building the things we planned to build.” This is solving too small of a problem. Yes, we build stuff, but not because someone asked us to build stuff, but because we want to solve problems for our customers.
To help a team become oriented to solving problems for customers, instead of building stuff because “it is at the top of the backlog.” We need to help them take a small series of steps.
Better? Or Just Different?
I felt it viscerally the first time I heard my colleague Anita Lessard ask a team this question – “Would that be better, or just different?”
We need the team to have a shared understanding (or a shared opinion, anyway) about how “more” becomes “better.” While uncomfortable for some teams, this is always achievable – because all we are doing is capturing the knowledge in the room. Documenting an opinion.
The first step is have the team create a line from “not at all solved” to “best possible solution” and have them articulate how much better the solution will be, after adding these features. The measure can be subjective, relative, whatever. We just require everyone to align on the notion that “adding this stuff” is “this amount better” objectively.
This is, of course, not enough. Someone has an opinion already that “more = better.” All we’ve done is make sure we share an understanding of this opinion. we have more work to do.
The second step is to ask how much better should we ultimately be? Because “the best possible solution,” in addition to often being infeasible, is usually a waste.
Ask yourself if the difference between “the best possible solution” and “almost the best possible solution” is a distinction without a difference. How much incremental revenue would we expect to generate with one versus the other?
Is “the best” better than “almost the best,” or is it only different?
Mapping with Intuition
Those final incremental gains are both harder for us to achieve, and less relevant to our customers, because the customer’s orientation to the problem is one of finding satisfaction with any given solution. The customer’s orientation is not ours. Customers typically experience diminishing returns.
While we see our solutions as becoming progressively better, those improvements are becoming progressively less relevant to our customers. Because of diminishing returns.
We use our intuition about how much satisfaction our customers will find in progressively “better” solutions.
This is how we leverage our intuition (developing a Kano model, or other translation) to develop an outside-in orientation to value around problem solving.
Again, we start by capturing our internal point of view. I like to break the reluctance with the phrase – “with the people in the room right now, with the knowledge in the room right now…”
We can decouple the scary decision to do something based on what we believe from documenting and aligning on what we believe.
Sometimes what we do is acknowledge that we have no idea what our customer cares about or would find satisfying. This is an excellent, outstanding, superb thing to realize before we’ve designed the solution, planned the release, or built the things. Because we have time to do something about it.
The Risk of Being Wrong
Sometimes the risk of being late overwhelms the risk of being wrong. So we now, instead of rushing blindly ahead without asking if it is valuable, declare, eye’s open, that we are rushing ahead with only the hope that it will solve our customer’s problems. As a former client liked to say – “hope is not a strategy.”
With an orientation to building things, we ask “how many more things can we build in this sprint?” With an orientation to solving problems, we ask “how much better can we be at solving this customer’s problem?”
This simple (yet difficult) shift in orientation de-risks the plan. We become far less likely to build things which don’t matter to our customers by starting with the question – “how much will this matter to our customers?”
Published on Java Code Geeks with permission by Scott Sehlhorst, partner at our JCG program. See the original article here: Intuition Enables Problem Solving Opinions expressed by Java Code Geeks contributors are their own. |
