Tag Archives: build-measure-learn

Applying Lean Techniques in a Big Company: The “Hothouse”

Large companies are always trying to find ways to move at “startup speed” or “digital speed”. The challenge often times is quite simply people: there are just too many of them to keep aligned in order to move swiftly. For any initiative, there are usually multiple stakeholders and affected parties. That means multiple opinions and feedback cycles.

It’s easy to say decision making should be centralized, but the reality is it’s much harder to execute in practice. Even a 1,000-person company has multiple departments, and bigger companies often have sub-departments. If I’m driving a new initiative that will materially impact the customer and/or the business, the fact of the matter is I need to ensure I’m actively coordinating with many of these groups throughout the process, like marketing, operations, call centers, brand, legal, IT/engineering, design, etc. That means not only coordinating with those departments heads (usually VPs), but also their lieutenants (usually Directors) who are responsible for execution within their domains and control key resources, and thus have a material influence over the decisions of the department heads.

In addition, large companies are often crippled by their own processes. Stage-Gate type implementations can be particularly notorious for slowing things down with the plethora of paperwork and approvals they tend to involve.

All of this means tons of emails, socialization meetings, documentation, and needless deck work. All of which is a form of waste, because it prevents true forward progress in terms of driving decision making, developing solutions, and getting them to market.

Initiatives involving UI are particularly susceptible to this sort of corporate bureaucracy for the simple reason that UI is visual and therefore easy to react to, and everyone feels entitled to opine on the user experience. Once, one of my product managers spent a month trying to get feedback and approvals from a handful of senior stakeholders on the UX direction for his initiative. A month! Why did it take so long? For the simple and very real reason that it was difficult to get all these senior leaders in the same room at the same time. What a waste of time!

So how to solve for this? Several years ago, my colleagues and I faced this exact challenge. While an overhaul of the entire SDLC was needed, that takes time in a large organization. What we needed was something that could accelerate decision making, involve both senior stakeholders and the project team, yet be implemented quickly. That’s when we hit upon our true insight: What we needed was to apply lean thinking to the process of gaining consensus on key business decisions.

And that’s how we adopted an agile innovation process that we called a “Hothouse.” A Hothouse combines the Build-Measure-Learn loop from Lean Startup with design thinking principles and agile development into a 2- to 3-day workshop in which senior business leaders work with product development teams through a series of iterative sprints to solve key business problems.

That’s a mouthful. Let’s break it down.

The Hothouse takes place typically over 2 or 3 days. One to three small Sprint teams are assembled to work on specific business problems throughout those 2-3 days in a series of Creative Sprints that are typically about 3 hours each. (4 hours max, 2.5 hours minimum.) Between each Creative Sprint is a Design Review in which the teams present the deliverables from their last sprint to senior leaders, who provide constructive, actionable feedback to the teams. The teams take this feedback into the next Creative Sprint.

This iterative workflow of Creative Sprints and Design Reviews follows the Build-Measure-Learn meta pattern from Lean Startup:

Hothouse Build-Measure-Learn

During the Creative Sprints, teams pursue the work using design thinking and agile principles, like reframing the business challenge, collaborative working between business and developers, ideation, user-centric thinking, using synthesis for problem solving, rapid prototyping, iterative and continuous delivery, face-to-face conversation as the primary means of communication, and team retrospections at the start of each sprint.

The Hothouse is used to accelerate solution development for a small handful of key business problems. So job #1 is to determine the specific business problems you want to solve in the Hothouse. The fewer, the better, as a narrow scope allows for more focused, efficient and faster solution development. For each business problem, teams bring in supporting material, such as existing customer research, current state user experience, business requirements, prototypes, architectural maps, etc. as inputs into the Hothouse. The expected outputs from the Hothouse depend on the business problems being addressed and the specific goals of the Hothouse, but can take the form of a refined and approved prototype, prioritized business requirements or stories, system impacts assessment, high-level delivery estimates, and even a marketing communication plan.

Hothouse process

At the end of the Hothouse, the accepted outputs becomes the foundation for further development post-Hothouse.

I’ve been part of numerous Hothouses, both as a participant and facilitator, and I’ve seen Hothouses applied to solve business challenges of varying scope and scale. For example:

  • Re-design of a web page or landing page.
  • Design of a user flow through an application.
  • Development of specific online capabilities, such as online registration and customer onboarding.
  • A complex re-platforming project involving migration from an old system to a new one with considerations for customer and business impacts.
  • An acquisition between F1000 companies.

The benefits to a large organization are manifold:

  • Accelerates decision making. What typically takes weeks or months is completed in days.
  • Senior leadership involvement means immediate feedback and direction for the project team.
  • Ensures alignment across all stakeholders and teams. The folks most directly impacted — senior leadership and the project delivery team — are fully represented. By the end of the Hothouse, everyone is on the same page on everything: the business problems and goals, proposed solutions, high-level system impacts, potential delivery trade-offs, priorities, and next steps.
  • This alignment serves as a much-needed baseline for the project post-Hothouse.
  • Bottom-line is faster product definition and solution development, which speeds delivery time-to-market.

A Hothouse can help you generate innovative solutions to your organization’s current problems, faster and cheaper. More details here. If you’re interested in learning more about agile innovation processes like the Hothouse, or how to implement one at your organization, reach out to me via Twitter or LinkedIn.

Disclaimer: I didn’t come up with the term Hothouse. I don’t know who did. But it’s a name we used internally, and it stuck. I think the original methodology comes from the UK, but I’m not sure. If you happen to know if the name is trademarked, please let me know and I’ll be happy to add the credit to this post.

“Stakeholder Development”: Using Customer Development on Internal Stakeholders

In my last post, I introduced the Product Canvas — my iteration of the Business Model Canvas — as a simple and quick way to capture my idea for a product. I’ve also used it as a communication tool to share my product vision and get early feedback, which is critical in the beginning stages of exploring a new product opportunity.

I’ve been sharing the Product Canvas with anyone who’s asked, and early feedback has been encouraging. One of the biggest things that seems to be resonating with folks is the Key Stakeholders box.

Product Canvas - Key Stakeholders

Look, I’ll admit, managing stakeholders is cumbersome, tiresome, and at times a pain. There, I said it. Admit it: you’ve felt that too. In my research on the business case process, a large majority stated that maintaining stakeholder support and alignment is important, but a challenge.

But I’ve learned the hard way that identifying and aligning stakeholders is really important for any initiative. So that’s why I put it in the Product Canvas. The reality is lack of stakeholder support can kill any brilliant idea at any stage.

When I came across Steve Blank’s Customer Development methodology, I wondered if its principles could be applied to internal stakeholder support. In other words, I wondered if it was possible to “develop” stakeholders too?

Here’s the Customer Development process. Steve’s bottom-line advice is to “get out of the building”.

Customer Development

So if apply this to “Stakeholder Development”, I’m thinking the process would look something like this:

Stakeholder Development

In this case, the bottom-line activity is to “walk the building”!

I figured this provided me as good a workable framework as any to identify, build and grow stakeholder support, and then I decided to put it to the test.

Through much trial and error, here are some tactics I’ve applied to Stakeholder Development. I’ll admit I haven’t fully cracked the code, and continue to experiment and learn. By sharing here, I’m hoping others may try as well and share their feedback.

I try to follow a systematic process for identifying my stakeholders, sharing my vision, capturing their feedback, and creating traction. I’ve been experimenting with applying Lean Startup’s Build-Measure-Lean loop for the purposes of doing this, and over time, I’ve developed a basic meta pattern:

stakeholder_dev_loop

So now that I’ve got a workflow I can follow, my first step is to identify who I think are my primary stakeholders, and I capture this in the Key Stakeholders column of my Product Canvas. Sometimes I already know ahead of time. In that case, I simply list them in the Product Canvas. But I have been in situations where I wasn’t entirely sure who were my key stakeholders. In this case, I capturing my hypothesis for who they may be.

I also try to identify a possible executive champion or sponsor – something I’ve learned is practically a requirement in a larger organization to ensure the success of any initiative.

So my Product Canvas could look something like this:

Product Canvas - Key Stakeholders example

I’d have actual names in the box, of course. If I don’t know who my executive sponsor will be (insider’s tip: it’s not always your boss), I don’t put a name, but I definitely call it out so it’s always at the forefront.

Next, I formulate hypotheses to approach my potential stakeholders. Going back to the Stakeholder Development flow above, notice a key question is “What are their agendas?” Remember: everyone has their own set of priorities. Some are visible, like a project deliverable; but some are invisible, like organizational political pressures. (Like it or not, these exist.) The more knowledgeable I can about their priorities, the better I can position myself to either gain their support or counter their arguments. At worse, I’ll have identified a potential detractor early on.

I then “walk the building”, reaching out and setting up meetings. For stakeholders with whom I don’t have a close relationship, who barely or don’t know me, I try to figure out ways to get an intro, just like one would do with customer interviews.

Setting up and conducting these conversations may be time consuming, but they are invaluable to validate who are my real stakeholders, and what I’ll need to do to get their buy-in.

I maintain a simple log to track my progress that I call my Stakeholder Development Tracker:

Stakeholder Development Tracker

There have been times I’ve discovered that someone who I thought would be an important stakeholder, actually isn’t. Great: I just mark their Role and Status as as N/A, and move on. Other times, I discover that someone I originally hadn’t identified is actually going to play a significant role in the approval and/or execution of my project.

Stakeholder Development Tracker Example

As I validate who are my true stakeholders, I update my Product Canvas.

product-canvas-key-stakeholders-iteration

These stakeholders are the ones I really want to focus on, the ones with whom I want to create traction. If I play my cards right, I can convert them from supporters to advocates to where they are actually personally vested in the success of my initiative.

As I said, I’ve been experimenting with this as a framework. It’s a work-in-progress, and I’ve enjoyed some success. Give it a whirl yourself, and let me know what works or doesn’t. If you have an approach to Stakeholder Development that’s worked for you, please share.

Top 7 Lessons Product Managers Can Learn From Lean Startup Machine

A few weekends ago, I participated in the Lean Startup Machine workshop held in Washington DC. For some time now, I’ve been thinking about how Lean Startup principles can be utilized to drive product innovation and if they can help product management become more efficient in driving product development and delivery. The Lean Startup Machine (LSM) workshop offered an opportunity to gain hands-on learning in applying Lean Startup techniques. The workshop proved to be an unforgettable experience.

Here are the top lessons I learned from the workshop and how they’re applicable to product management.

1. “Lean Startup is about running the simplest experiment to validate a business assumption.” – @SargeSalman. As I’m learning myself, there are many misconceptions about Lean Startup. Chief among them is that lean means cheap. It does not. Lean means not being wasteful. And the way it’s applied to business problems is by challenging you to think critically about the assumptions underlying your business or product idea, and then to systematically and rigorously test them to prove them true or false.

build-measure-learnLean Startup challenges the traditional business practice of using product releases as the as the metric of execution by espousing learning as the metric of progress through the use of validation/invalidation of one’s assumptions through testable hypotheses. As a product manager, this makes sense to me as one of the things I should be doing is thinking critically and analytically about my product solution.

2. Go talk to your customers. Constantly. Lean Startup starts with Customer Development, a method Steven Blank introduces in his book The Four Steps to the Epiphany. Customer Development asks entrepreneurs to “get out the building”, which is another way of saying, “go talk to your customers.” This exactly what product management should be doing.

As such, this should come intuitively to product management, because product managers should always be focused on the customer. What the Lean Startup movement has done, though, is provided a methodical way to think about and approach how to conduct customer research. At the LSM workshop, we were forced to continually go find and talk to customers. LSM goes beyond theory by providing its participants with a tool called the Validation Board to capture one’s assumptions, create experiments, document learnings, and make the next pivot.

3. Traditional product development is wasteful. On the surface, this systematic way of hypothesizing, experimenting and learning can seem slow, because it’s not visibly tangible. Whereas a requirements document is. And code is. So both business management and even product management get trigger happy to start getting some code written, as its a way of showing demonstrable progress and makes us feel good that the product is getting developed. After all, the sooner the product is out there, the sooner we can make money!

Unfortunately, this traditional approach gives us a false sense of progress. The LSM workshop was a valuable reminder that if you don’t spend time upfront understanding your customers and their needs, you will build products no one wants. I learned this the hard way from first hand experience when I built a first-of-its-kind web product that cost a lot of money and took 6 months to launch only to achieve a miserable 2% registration rate two years after its initial launch. Ouch.

4. You must have a strong team. Now, granted, product managers can’t always choose their team members. Yet, what LSM got me to think is how many product managers think critically about the kinds of team members they’d like and then actually ask for them? And even in the case where one cannot choose their team members, as the leader of that team, how many actually spend time cultivating team unity?

5. Leadership is always, always required. This falls from the above point. The LSM workshop groups participants into teams and each team pursues an idea that received the most votes from the participants themselves. My experience reinforced the need for strong leadership by the team lead. This not only means building strong team unity of purpose, but also being able to effectively arbitrate discussions and be decisive. Exactly what a product manager is supposed to do.

6. LSM will test your influencing skills. Leadership is about influence. Product managers need to be strong influencers and negotiators. At the LSM workshop, you are working with people you’ve never met before on a team, and under a stringent timeline all of you need to come together as a team and demonstrate progress. I found my influencing skills were strenuously tested during the workshop, and it was wonderful.

7. Your solution, while interesting, is irrelevant. Sounds familiar, right? A riff on the traditional product management mantra of “your opinion, while interesting, is irrelevant”, though this takes it to the next level and targets the proposed solution itself.

Customers don't care about your product

Entrepreneurs love their ideas. They love their solutions. And so do product managers. While I’m not saying entrepreneurship and product management are the same, like entrepreneurs, product managers are natural problem solvers and we’re passionate about our solutions. Heck, I get passionate about my product ideas all the time! But the sobering truth is that it’s infinitely more important to first be crystal clear on who is your customer and what is their problem. Because the customer does not care about your product.

The LSM workshop forces you to think about the customer and their problem first. During the workshop, I saw first hand how many people struggled with staying out of the solution zone, including, I must admit, myself. By validating your customer and problem hypotheses, you’ll be in a better position to provide a real solution that solves actual customer problems.

I would definitely encourage you to attend a Lean Startup Machine workshop near you. I’ve written a recap of the one I attended on my blog and explain why I recommend product managers should attend LSM.

Have you attended an LSM workshop? What was your experience like? Have you tried applying Lean Startup principles in your work? Please share!