Tag Archives: lean startup

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!

Why It’s Better To Be Smaller When Implementing Agile In A Large Company

Having done many waterfall projects, I was recently part of an effort to move a large organization to an agile software delivery process after years of following waterfall. I’ll be blunt: it was downright painful. That said, I’d pick agile over the mutlti-staged, paper intensive, meeting heavy, PMO driven waterfall process I encountered when I joined the organization.

Although the shift was painful, it was a terrific educational experience. Based on lessons learned, we adopted certain principles to guide our approach to implementing agile in the organization.

Dream big. Think smaller.

This means having a vision for what the solution will look like and the benefits it will provide customers, but then boiling it down to specifics to be able to execute. For example, at one of my former gigs, we had identified the need to make improvements to our online payments process, and captured over 20 different enhancements on a single slide under the title of “Payment Enhancements”. (Yes, in very tiny font, like 8-point.) Those enhancements were beyond simple things like improving copy or the layout of elements. Each enhancement would have involved material impacts to back-end processes. As such, “Payment Enhancements” is not an epic, or at least, it’s a super big and super nebulous one that cannot be measured. Rather, I argued that each bullet on that 1-pager could be considered an epic in and of itself that could be placed on the roadmap and would need to be further broken down into stories for execution purposes.

Thinking smaller also means considering launching the capability to a smaller subset of customers. Even when pursuing an enhancement to an existing product, it’s important to ask whether the enhancement will truly benefit all customers using your product or whether it needs to be made available to all customers on day 1. Benefits of identifying an early adopter segment: (1) get code out faster, (2) lower customer impact, (3) get customer feedback sooner that can be acted on.

Be sharp and ruthless about defining the MVP.

Lean Startup defines MVP (Minimum Viable Product) as “that version of the product that allows the team to collect the maximum amount of validated learning from customers”.

(We think) we know the problem. We don’t know for certain the solution. We have only a vision and point-of-view on what it could be. We will only know for certain we have a viable solution when customers tell us so because they use it. So identify what are the top customer problems we’re trying to solve, the underlying assumptions in our proposed solution, and what we really need to learn from our customers. Then formulate testable hypotheses and use that to define our MVP.

Make validated learning the measure

In the war of SDLCs, I’m no blanket waterfall basher nor true believer of agile. But from having done a number of waterfall projects I’ve observed that it’s typically been managed by what I call “management by date”, or more often than not, make-believe date.

As human beings, we like certainty. A date is certain. So setting a date is something that we feel can be measured, in part because a date feels real, it gives us a target, and in part probably because over decades we’ve become so accustomed to using date-driven project management to drive our product development efforts. The problem becomes that this gets us into the classic scope-time-budget headache, which means we’re now using those elements as the measure of our progress.

The thing is, scope, time and budget mean absolutely nothing to the customer. What really matters is whether customers find value in the solution we are trying to provide them. Traditional product development and project management practices don’t allow us to measure that until product launch, by which time it may be too late.

So we need to make learning the primary goal, not simply hitting a release date, which is really a check-the-box exercise and means nothing. Nothing beats direct customer feedback. We don’t know what the solution is until customers can get their hands on it. So instead of working like crazy to hit a release date, work like crazy to get customer validation. That allows us to validate our solution (MVP) and pivot as necessary.

Focus always, always on delivering a great user experience

Better to have less functionality that delivers a resonating experience than more that compromises usability. A poor UX directly impacts the value proposition of our solution. We need look no further than Apple’s stumble on the iPhone 5 Maps app. (Ironic.)

Continuous deployment applies not just to agile delivery, but also the roadmap

Over four years ago, Saeed Khan posted a nice piece on roadmaps where he said:

A roadmap is a planned future, laid out in broad strokes — i.e. planned or proposed product releases, listing high level functionality or release themes, laid out in rough timeframes — usually the target calendar or fiscal quarter — for a period usually extending for 2 or 3 significant feature releases into the future.

The roadmap is just that: a high-level map to achieve a vision. Not a calendar of arbitrary dates to hit. Too many roadmaps seem to suffer from the same date-driven project management approach.

For most established software products, I typically advocate having at least a 12-month roadmap that communicates the direction to be taken to achieve the vision and big business goals. It identifies targeted epics to achieve that vision. The vision is boiled down to a more tangible 3-month roadmap. That’s the stuff we want to get done in the next 3 months and what the agile teams need to work on.

Create an accountable person or body that actively looks at the roadmap on a monthly and quarterly basis. On a monthly basis, this body helps the agile Product Owner(s) prioritize the backlog against the 3-month roadmap. On a quarterly basis, this body evaluates overall progress against the 12-month roadmap. As such, 12 months is a rolling period, not an annual calendar of unsubstantiated promises of delivery.

What has your experience been implementing agile in your organization? What principles does your organization follow in executing an agile process?