I’m a partner at Zeitspace, a software product design and development consultancy. We’re fortunate to work with clients on both early stage and mature products. Regardless of the stage, the end goal is always the same: build the right thing for the right audience. Sounds simple, it isn’t.
Fortunately, as product design and management as disciplines have matured, so have our frameworks. Our clients range from experienced ‘Agilists’ to those new to software development. Regardless of a client’s experience or process maturity, we use Lean Practices to maximize the value we deliver as well as to collectively improve our craft.
Zeitspace sponsors Product Tank Waterloo to advance Lean Product practices here in our community. One of my co-organizers, Sarah Kerr is presenting Lean 101 at our February MeetUp.
Even if you’re an experienced Lean Practitioner, it’s always interesting to hear how others tackle problems we all face. I’ve worked with Sarah in two separate tours of duty and her analytical approach has always impressed me.
In this presentation, she’ll cover some foundational elements we all use everyday to approach product and feature design. The following is a brief overview of Lean Principles I’ve found to be essential in guiding products and clients.
Whether you’re a fan of Ash Maurya’s Lean Canvas or Alex Osterwalder’s Business Model Canvas, both are great ways to get ideas out of your head and onto paper in systematic way.
Unlike traditional business plans, the canvas is fast. You can easily develop your canvas in under an hour because it’s efficient and to-the-point: the canvas is limited to 1 page, so, you’ll need to focus on only the elements that are key to your product. The canvas is also convenient, you can easily share it with others and they can digest your product in less than 5 minutes.
Any new product or feature typically has several hypothesis that success hinges on. Lean Practices advocate for testing your riskiest hypothesis as early as possible. What you’ll test, depends on where you are in the product cycle:
A simple way to prioritize your hypotheses is to plot them on two axis: Number of Unknowns vs Likelihood to Kill the Product. The result will categorize your hypotheses into 4 simple quadrants. You want to focus on the hypotheses that are in the aptly named Focus quadrant where they have the biggest potential to kill your product and have the most unknowns.
With your riskiest hypotheses identified, now it’s time to design an experiment that can validate or just as importantly, invalidate your hypotheses. Ash Maurya has a helpful post on running Lean experiments. The place I see most teams struggle is, as Ash describes, turning your leaps of faith into a falsifiable hypothesis. It’s sometimes hard for teams to be really honest and concrete with their expected outcomes for fear of failure.
Specific testable action will drive expected measurable outcome.
So for example, you might phrase a frequent feature request hypothesis as:
“Adding Feature X will drive an additional $10K in MRR.”
Getting everyone on the same page on the expected outcome is crucial. It’s also crucial to understand that invalidating your experiment is not failure. This can be a huge challenge culturally but remember that we wouldn’t have gunpowder, microwaves or penicillin if unexpected outcomes didn’t happen. The goal is to learn from your experiment. Regardless of the outcome, you’ll have new insight to act upon.
There is no such thing as a failed experiment, only experiments with unexpected outcomes.
— Buckminster Fuller
The most important outcome of your experiment is learning. You’re playing a long, 3 plus year, game where you’re advancing iteratively towards your ultimate vision. That vision needs to be anchored by your minimum success criteria (e.g. a specific revenue target). It is expected that you are correcting your course as markets and competitors react as well as your understanding of the problem space and your customers deepen.
Ash Maurya’s 3x3x3 Vision Strategy and Product timeboxing
Indoctrinating a process where you conduct Lean Sprints, with frequent measuring of specific outcomes is critical to success. Speed is important here: the whole company needs to be assessing outcomes and insights on a regular basis. The whole point of Lean isn’t that you’re doing things inexpensively but that you’re freeing yourself from heavy process, tooling and admin that needlessly slows you down. John Cutler has a fantastic point about this:
From John Cutler: “When feedback loops are long, output will always be valued over outcomes”
But don’t take my word for it, c’mon out to tonight’s session and learn from Sarah’s perspective and experience.