Tag Archives: product development

How To Streamline Your Product Development Process

By Emily Hunter

Many businesses are sustained and driven by product development. From small businesses to multinational corporations, the creation of new products is vital to market survival, especially in a world where trends, likes, and dislikes appear to change on an almost daily basis. Because of the swiftly changing market, many businesses have looked for ways to make the standard development process a little faster, or at least a little smoother.

In standard product development, there are several stages in the process like idea generation, screening, commercialization, and so forth until the product is finally ready for launch. While this development process works well, and is still in use by a great many organizations, it doesn’t always foster quick change and a fast development cycle.

A Holistic Emphasis

Holistic processes, used by major companies in the United States and Japan, do not get rid of a company’s stages of development, but merge them. When the idea is born, for example, it might move through the development team before the screening team compares and contrasts it with new product-related ideas, but both ends work in conjunction with one another. Instead of moving through incremental stages, everyone simultaneously contributes until the product is done.

Today, when a product needs to be built before the next big thing comes along, flexibility is a must. Having more hands on deck during product development requires more trial and error than the standard linear method. However, it also necessitates more communication between departments, which fosters transparency and openness through every level in a company. Once everyone understands what the other departments do, they are far more likely to take advantage of cross-departmental collaboration, allowing the company as a whole to reap the benefits of teamwork.

A Little Push

As always, development begins with an idea. In many cases, it’s a very broad idea — one that requires limits to be stretched and tested. When ideas arise in big companies, they are usually generated and imposed from above, unlike small companies, which can think big and aim for something they’ve never tried before. The problem with “thinking big” is that big ideas are often daunting to execute in real life.

Naturally, the idea has to be feasible. It also has to have a time limit. It’s going to be challenging, so everyone involved will have to be pushed a little — by themselves, by management, by the other members of their team. Enforce deadlines, maintain high standards, and monitor the quality of work, but do so within reason. Too much pressure can destroy a team, but just the right amount can drive people to achieve accomplishments they never believed possible.

A Team of Their Own

Product development teams tend to be extremely independent. Basically, they are given a concept, and they build a design around that idea. If the people involved are qualified in their specializations, the project will gain a life of its own. If upper management is involved in starting this kind of team, they should remember that such an arrangement works better if they just stay out of it. Shifting already established parameters as the potential to destroy the entire process.

Over time, the team will develop its own personal goals in an effort to complete the task in the time allotted, often fostering a strong sense of unity through the shared task. In effect, management won’t have to move the goal posts because the team will do this on their own. With each victory inspiring them to further success, every challenge overcome will instigate another even more difficult challenge in a kind of snowball effect.

Streamline Appropriately

The process of streamlining product development is great for many companies, but it is not for everyone. A freeform creative process tends to involve a great deal of overtime. For instance, a team that is not willing to put in the extra creative hours to bring an idea to life would be better off with the standard, more stratified process. Likewise, the naturally unstable and flexible teamwork setting of a holistic development process is not conducive to a huge project involving hundreds of people.

Some companies are run by a single individual who basically invents the products on his or her own and then gives the specifications to a design team. In this cases, it’s best to simply design the product as ordered rather than trying to improve upon the design.

Dealing with Change

It’s not easy to do something different from the standard procedure, especially the “old way” is deeply engrained into a company’s routine practices. However, change is often necessary. A new streamlined product development process may feel a little strange at first, and it may seem like it’s not quite working, But every new process takes some getting used to. Whether it’s a new software program or new machinery, mastering an innovative new process typically produces fantastic results.

Emily Hunter has been writing about business topics for many years, and currently writes on behalf of the product development specialists at Pivot International. In her spare time, she cheers for Spirit of Atlanta, Carolina Crown and Phantom Regiment, creates her own sodas, and crushes tower defense games. Follow her on Twitter at @Emily2Zen.

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.

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?

The need for speed

In this post, I’d like to talk about using a “co-location” approach for defining and developing a software product, and I’d love to get your thoughts. More about what I mean by co-located product development in a moment. First, some broader context.

As human beings, we want things to be faster, better, cheaper. And that’s certainly true of software development. Many methodologies have been invented to get software out to the marketplace quicker: waterfall, CMM, UML, Stage-Gate, rapid prototyping, extreme programming, user centered design, and, of course, agile. Recently I’ve started exploring the Lean Startup methodology pioneered by Eric Ries, which is a sort of lean software development process geared for startups that uses the principles of reducing waste, iterative development cycles with constant customer feedback loops, and metrics measured outcomes to achieve product/market fit.

One other methodology (if you can call it that) I’ve experienced in the past is a “co-location” approach. I basically describe this as “identify a business opportunity to solve for; then take a bunch of people across the company to represent the business, implementation, operations and IT, throw them into a room, and don’t let them out till they’ve designed the product / solved the problem.” The thinking here is that if we take our best and brightest, and focus them in singular fashion on solving a particular problem under a tight deadline, they’re bound to come up with magic, right? Isn’t that what saved the day in Apollo 13?

I’ll be honest. Whenever I hear co-location, I have a major ugh moment. Here’s why. I’ve experienced co-location twice. Once was a situation where the business problem was outlined, the group ideated for a considerable amount of time, and then quickly began defining the product. Because IT (or IS or Software Engineering or whatever your organization calls it) was also involved, they could provide important system knowledge to ground the conversation technically, and at the end of the multi-week process provide an estimate as to the level of effort (LOE) involved in developing the solution. The LOE would be a pointer to development cost and time to market, a key consideration used by senior management in prioritizing projects. Another was in a war room type situation where due to a large number of quality issues with the software development, the product launch was in critical jeopardy, so an emergency “all hands on deck” situation was called where the entire dev staff + QA + product management were put into a room together to get the software out on time.

Both situations involved a fairly large group of smart individuals working collaboratively everyday over a multi-week period for a desired outcome. Both situations resulted in a shoddy and costly product that received at best lukewarm responses from end-customers.

Here’s why they failed:

  • Focus on the wrong outcome. In my first scenario, the situation was set up with the right intentions, but because getting an LOE was the identified output from the exercise, the focus inevitably and quickly became defining a product with a low LOE, with low LOE being assumed as a proxy for faster time to market. In my second scenario, the focus became a race to production, leading to an inevitable sacrifice in – yep – quality.
  • Lack of product definition. This applies more to my first scenario. The desired product was described in broad strokes (like describing a flashlight as “having the ability to light the room when turned on”), but these broad strokes meant IT was dangerously filling in the gaps, leading to an overly inflated and ultimately discardable LOE.
  • Product definition by committee. Everyone has an opinion. So in a co-located situation, everyone’s opinion is heard, none are discarded, and in the end you have a diluted product that may satisfies everyone’s egos, but doesn’t truly solve the customer’s problem. Pragmatic Marketing Rules #4 and #6 are violated here:
    • #4: “The building is full of product experts. Your company needs market experts.”
    • #6: “Your opinion, while interesting, is irrelevant.”
  • Product definition by the business person. This is the opposite of the above. If one or more business people are in the room (this could be the marketing director, business development or sales guy, or a GM), there is a tendency for everyone else to defer to them. The non-business people will rightfully look at them asking “So what do you want?” The business folks have an understandably deeply vested interest in the success of the product (because after all, they’re paying for it!), and so will want to control how the product is defined. The problems are: (1) business folks are typically terrible at product definition, and (2) none of these folks are market experts, which brings us to the next problem.
  • Lack of market, especially customer, input. This is perhaps the most cardinal sin of all, unforgivable violations of Pragmatic Marketing Rules #2 and #8:
    • #2: “An outside-in approach increases the likelihood of product success.” Co-location strikes me as definitely a tune-out approach.
    • #8: “The answer to most of your questions is not in the building.” Customer research may have been done upfront in defining the business opportunity, but is often neglected in validating potential solutions during the co-location effort.

Another issue I have with co-location is the resource commitment. Co-location requires a bunch of people across the enterprise to be committed to the process for a fixed length of time. That means anything else those individuals may have been working on at the time must be dropped or put on hold. The larger the organization, the larger the ripple effect, as each of these individuals are likely working on other initiatives with others folks across the enterprise not a part of the co-location effort. This means business comes to a standstill for those efforts. This seems inefficient and wasteful.

The Apollo 13 approach may be great in emergency situations, when a creative solution is needed for an extraordinary situation. Co-location may make sense when there is a need to solve a problem that is immediate and urgent. But it does not strike me as a sustainable way to define and develop software products.

So why is co-location used? I can identify two reasons. First, back to my opening remarks. There is a need for speed. We have a business problem, and if we get our best folks to focus on it, we should be able to get to a solution quickly. Voila! Problem solved in a few short weeks!

Second, prioritization. No business can pursue all opportunities at once. Senior management must constantly make difficult trade-off decisions on which problems to solve, products to develop, and projects to fund. An LOE is a critical piece of input into prioritization decisioning. Co-location’s appeal is that an LOE can be produced in a short timeframe to help with that decisioning, and every key stakeholder has been a part of that process.

The problem is this is all an illusion. Co-location gives the perception of speed. The LOE is typically either inflated, because of the lack of proper product definition, or is gratifyingly low only because the product has been so watered down as to render it ineffective in truly solving the customer’s problem. Either way, quality suffers.

Now, I admit this has been my personal experience, and I certainly don’t profess my experience to be a proxy for wider market truth. (My opinion, while interesting, is irrelevant.) So I shall now take an outside-in approach and tune-in to hear from you. Have you ever experienced a successful co-located product development effort? Does co-location ever make sense for software product definition and development? If so, when? Here’s a really fun question: if your management believed in co-location and you did not, how would you convince them otherwise? Are there outcome defined ways, quantitative or measured otherwise, to prove your case?

Like This!

Add to: Facebook | Digg | Del.icio.us | Stumbleupon | Reddit | Blinklist | Twitter | Technorati | Yahoo Buzz | Newsvine

Lean Startup in a Large Company

I’ve started reading Ash Maurya’s book, Running Lean, and have begun educating myself on Lean Startup practices, a term trademarked by Eric Ries. It’s is a fascinating approach to launching a startup, and has a passionate cult following that’s trying to break through into mainstream practice. Being a product guy, I view startups as new product development – both require business modeling, validation with customers, investment, product build and market launch. (I’m not saying a startup is the same as NPD in an established company – I’m just saying they share similar traits.)

I like Ash’s Lean Canvas that he discusses in his book. For capturing an initial vision of a business model concept, it’s fast, concise and portable, with key building blocks identified all on one page vs. creating a 20-page or 15-slide business plan that takes too long to build and no one will ever read anyway. Multiple models or canvases can easily be sketched out in a single afternoon. It allows for fluidity, as sections can be left blank and then filled in or refined based on learnings. It also forces thinking in the present with a “get it done” attitude. Most importantly, it uses a customer-centric or “tuned in” approach. (Tuned In is another book I admire.)

Ash candidly admits the methodology he proposes in his book is for web application startups. But at the end, he throws down a challenge: “What about ‘Running Lean for X’?”

So I began to think:

  • Can Lean Startup practices be applied at an established company? At a large enterprise?
  • What about Running Lean for a B2B2C product?
  • And what if that B2B2C product wasn’t software, but a service?
  • Can Lean Startup practices be applied to Product Management?

This last question intrigued me the most, because I have always felt that Product Management could be more entrepreneurial in its approach, yet like almost all Product Managers, I’ve had Pragmatic, ZigZag, Crossing the Chasm, and other frameworks drilled into me as the gold standards for identifying, developing, positioning and launching market-driven products. If Lean Startup principles can be applied to Product Management at enterprise firms, does it challenge these tried and tested methodologies, evolve them, or – dare I say – render them obsolete?

Ash encourages his readers to field-test concepts and models first-hand. I like that approach. And because I do currently work at a large B2B2C company that sells services rather than software or tangible products, I’m doing just that. I started applying Running Lean and Lean Startup concepts on some new ideas I’m kicking around. The focus, as Ash encourages in his book, is “Validated Learning”. As I tried to capture my vision onto a Lean Canvas, I immediately ran into challenges:

Who is the real target customer? In B2B2C, consumers may be the end-users of the product, but what if an intermediary is actually the one paying for it? So do I have two target customer segments?

The first question cascades into a series follow-up questions.

Whose problems are we really solving? If I do have two target customer segments, do I have two sets of problems to address? Two sets of solutions? Different unique value propositions for each one?

How to succinctly capture the Solution? In B2B2C, doesn’t the product ultimately have to have features appealing to both the C and the B?

Revenue streams: The nice thing about B2B2C is you can get pretty creative with revenue models. In the services industry, you can get even more creative. And that’s where again I found the Lean Canvas constraining at first. How can you concisely capture a potentially complex revenue model?

And how do I capture all of this on a 1-page Lean Canvas?

In the end, I decided to focus on the C, approach it strictly from the customer standpoint, and treat the B as a channel, largely because it made the exercise easier and thinking from the customer’s perspective comes more intuitive to me. I’m not saying this is the right approach. I’m saying it’s what allowed me to get through the exercise (so far).

I’d love to hear from you. What do you think?