#47 - Overcoming Bureaucracy with "Multi-Threading" (A Tale of Two Realities)
Structure:
Background
Two parallel realities
A series of power points to help you keep moving fast, even in a large organization
Do you know what just grinds my gears? Gridlock. Traffic. Being stuck standing in line, with no movement.
After 30+ years of reflection, I’ve concluded that the lack of movement is one of the things that frustrates me the most, and it doesn’t just happen in traffic: it happens at work.
Whenever I’m working in a particularly large organization (read: many layers of approval required to pivot strategy), one of the tactics I’ve fallen in love with is multi-threading. When I use this word, I do not mean “multi-tasking”…
Multi-threading is when we fast-track an early MVP (minimum viable product) of something to market to get real feedback, while continuing to work on subsequent product releases that benefit from more internal stakeholder and external customer feedback.
Used in a sentence: “Let’s multi-thread this. Target MVP1 launching in 3 weeks to a limited set of customers, while we work through MVP2, MVP3, and Full Launch 1 over the coming 6 months” - Source: brain
Here are two parallel realities: one with and one without multi-threading
The Situation:
Imagine you’re sitting in a large management layer meeting with twenty people. You work at a digital health company that provides telehealth care specifically for people struggling with sleep problems.
During this meeting, one of your colleagues, Jessica, is presenting on the idea of adding a new product offering around faster on-demand access. One of the things she says is, “Many customers are asking for the ability to quickly access a practitioner to get quick advice on things like bedtime rituals, dietary modifications, and mental exercises for calming your brain down before bedtime.”
This is where the stories diverge. What usually happens next?
Reality 1 without multi-threading (duration: 30 weeks to customer feedback):
Week 1: Jessica gets loads of ideas about how to act on the customer feedback
Week 1-7: Jessica suggests that the team spend the next 6 weeks learning more about the feedback they’re receiving + develop 2-3 concepts to solve the problem
Week 8: Team presents to management group again, and gets yet more feedback. Reminder: they are not presenting to customers; they’re presenting to their own internal team
Week 8-16: Jessica then says they’ll spend another 2 months building out an MVP
Week 16-18: Then Jessica and team will come back to leadership group with concepts for how to act on feedback, and they — again — get loads of feedback. They go back to drawing board, and they will get another chance to present in two weeks
Week 18-22: They come back and present their concept again, and the group once again provides feedback that will take the team another month to work through
Week 22-26: This process continues until the original concept has been shaved and formed into something that is almost totally devoid of hutzpah
Week 30: After legal and compliance review, eventually a green light is given for an MVP launch, and the team is congratulated for their impact.
After 30 weeks of effort, a customer finally sees the MVP for the first time… And they don’t give a crap, because they found a platform to do what they needed three months ago
Reality 2 with multi-threading (Duration: 9 weeks. 21 weeks shorter than reality 1, and far more exciting + less painful for the core working team)
Week 1: Jessica gets loads of ideas about how to act on the customer feedback
Week 1 (Friday afternoon): Jessica and a tiger team get together for a 3-hour working session with the goal of having an experience mocked up in Figma, with steps, preliminary views of who on the team will drive the tests, and they end with a list of 10-20 customers who’ve expressed interest
Week 2: The team reaches out to 10 of their customers and asks if they would be interested in giving feedback on “a new experience” that your team is testing. 4 people respond
Week 3: You talk to four people and get feedback, and work that feedback into updated mock-ups
Week 4: Development on new feature set, outreach to other 10 customers. Six respond this time
Week 5: You talk to five customers (one had to reschedule) and they actually click through this new experience and get to test drive it during this “alpha testing” call
Week 6: You come back to management with actual customer feedback, usage insights, and you also share a product roadmap of what the launch in three weeks will look like, and what future releases throughout the next year might entail. You also share metrics you’re targeting with each release, and enlist other leaders to lean into help (Marketing for GTM support, sales for targeted testing in the sales cycle, engineering for ongoing development support, product for ongoing feature refinement and market research)
Week 9: MVP does a limited, “early release” to a small subset of customers who have opted in to try the new feature. You get more usage data and feedback. This helps you to inform future releases
Week 30: You’ve had four separate releases that have iterated based directly on customer feedback, and you've also uncovered an opportunity to partner with another company to help scale the people resourcing required to bring this product to market across your entire 100,000-user customer base
(Don’t take this way… OR that way… take both ways)
Notice that the latter reality (above) resulted in a far higher-quality experience for customers and business growth
Because the team was nimble, and was given the ability to test with customers, and not just test with internal stakeholders. All work should have a customer validation plan.
Customer obsession is not internal-hierarchy obsession. I’ve found that internal stakeholder obsession leads to sustained mediocrity and a slower pace of innovation.
The bigger your company, the easier it is to be far away from customers. Distance to Customer should be minimized for EVERY SINGLE PERSON at a company. Everyone must have chances to either directly interact with customers or at least hear from them regularly. Customers Buy Products. Focus On Customers.
What is this not? This means do not just focus on making your boss or senior leaders happy. Yes, they are a stakeholder group. They are important. They should be engaged, but they are not the group you need to obsess about.
When you work in a big organization, you should — from the very beginning of an initiative — set the expectation that you want validated customer feedback from customers WHILE continuing to build out more mature versions of your product
And I think this is really the bottom-line takeaway here. The easiest way to implement multi-threading into your work is to immediately set a dual objective for your projects. Goal 1 should be getting validated feedback as quickly as possible. Goal 2 should be about the longer-term, more “polished” … “refined” vision.
Failure to do this will keep people pursuing perfection at the expense of progress. Startups inherently understand this and move far faster than large companies do as a result. While you’re in a smaller organization, do everything you can to protect being nimble and fast. While you’re in a larger organization, talk about multi-threading as a way to harness the spirit of a startup. Because, jeez, the vast majority of senior executives I’ve ever met tend to want to “move like a startup.”