Putting Lean to Work on a Top Secret, Disruptive Product
I’m leading design on a product with grandiose implications for humanity. Kinda like the X-men.
I’m leading design on a product with grandiose implications for humanity. Kinda like the X-men. It’s top secret, so I’ll try and paint the picture in metaphor. Okay, think of humanity as ants. Now imagine those ants all have time machines and ray guns! No that’s not quite right. Imagine the world’s brightest minds together in one place engaged in solving the big problems of our age…in real-time! That’s a little better.
The project is funded. The market is validated. We know there is a huge appetite for what we’re making. We’re also aware of corruption that works against fixing the system. We aim to disrupt that.
We’re looking to shape future behavior, and not so much looking at the behavior arising from the current broken systems.
When we think of lean, we think build—measure—learn. We think of validation. Testing assumptions. Getting an MVP in the market. But here we are wanting to enable a quantum leap in behavior and attitude. And it’s under wraps. How do we build—measure—learn in that context? Is it even appropriate to take a lean lens to this?
The answer is ‘Hell yes’. In fact it’s more important we do so. Projects that are secluded and funded are more vulnerable to being fatty and ending up way off base. Teams are at higher risk of breathing their own fumes when working in secrecy. And it’s all too easy to add waste by using old, comfortable methods. Historically, the work would go something like this: First there would be the idea. Then there would be a lot of research done by researchers. The designers would then design it. And finally developers would build it. This process is, of course, called waterfall. It’s an expensive and risky way to build products, we now know. A new best practice has emerged.
We can bring lean methodologies to a project like this. How we build is just as important as what we build and why. Let’s start with the how part.
How to Work Lean on Long-Term Projects
• Assemble cross-functional teams
We build small, cross-functional teams. We have designers and engineers working side by side with the product owner and a domain expert. The act of simply making something together brings about new angles and opportunities that would remain otherwise hidden.
• Work out loud
We keep true to the principles of the project while also testing for feasibility — it’s baked into the day-to-day work. We work together transparently to iterate trials against our blue-sky vision. Adjustment and assessment happens continuously. It takes a lean discipline to maintain a vision that keeps pace with your learnings.
• Work low-fi
It’s important to acknowledge that the starting vision is wrong, wrong, wrong. It will need to change as you’re building. So we work fast, low-fi and towards a common goal. We think aloud as a group, favor white-boarding to wireframes, favor hacking up screenshots rather than maintaining PSD masters. We favor the product over design artifacts and documentation. Get over it. Your product is the documentation.
• Maintain a shared understanding
This is a happy side effect of working out loud. There are no long documents or briefs to be updated and maintained. We are all experts. We all get it. We trust each other and we move as one to build the product.
Okay, but what about the what and why part? If we are flying under the radar, what external input are we using to correct course? That feedback loop is essential to ‘lean’.
How to Build—Measure—Learn on Top Secret Projects
This product’s development is more agile than lean. It’s intentionally being well-baked before real people use it in the real world (the reason for doing so is another post entirely). However, lean practices have had an undeniable and enormous impact on the mission, the client, and the product.
In lean fashion, we de-risk by testing hypotheses and shake out costly assumptions early. We embed lean epicycles of build-measure-learn into the agile development process. Here’s how…
• If the real world is off-limits, make a secret world
We mimic the real-world and test there. If the organization is large, you likely have access to safe people who match prospective customers. Use them for testing.
• Isolate high-risk assumptions
Here’s an example. The client had arrived at the inception armed with two years of upfront research, and felt strongly about building out 3 very specific interaction paradigms. The Neo team members wanted to validate that proposed solution.
• Listen to customers in your secret world
We set up phone interviews with safe subjects who fit nicely into the customer pool. We listened to detailed stories from these people. They’re important foot soldiers in the culture we are hoping to affect. If the solution doesn’t work for them, then it won’t succeed in the broader, global context.
They detailed their pains to us. They ranked them for us. We learned what motivates them to do their work. At the end we had a nice set of data points, and validated specific problems.
• Test hypotheses in your secret world
Next, we wanted to see if the same paradigms would rise to the top if we considered interaction models from scratch. So we set out on a time-boxed, blue-sky design exercise.
After quick internal iteration, we had a set of comps with which to test. From testing sessions, we arrived at interaction models that were in some ways similar, and in other ways different than what the client originally envisioned. What rose to the top were the aspects of those initial paradigms that were of highest value to the customer.
So that’s it. We create hypotheses from assumptions. We build tests (comps and quick prototypes), and we learn from testing them. Then we feed the learnings back into the product we’re building. As the broader team sees the benefits, they feel comfortable referring more customers for testing, thus growing our secret world to better match the real world with it’s varied, global actors.
