Create Your Business Case Using Customer Development

A few weeks ago, I spoke at the Modev MVP Conference and the Lean+Agile DC Conference about using a bootstrapped Customer Development approach to pursuing a new product idea in an existing company.

I talked about how the traditional product innovation process of writing a business case with long-term financial projections, then writing a big PRD, then doing development and launching doesn’t work, and presented a case study of a better approach that used Customer Development and Lean Startup practices that produced far more impactful results.

Here my slides from those talks (same set used for both):

How To Get Quality Customer Insights (Spoiler: It’s Not About Time)

A Sales Exec and I were debating whether amount of time spent with a customer is a measure of the quality of the customer interaction.

His argument:

Just curious — do you see 23 touches for 5 mins the same as 23 touches for 1 hour each — I think it is different and material.

From my perspective, I need to allocated a certain number of hours per week with customers, and believe that number in a normal week is likely 5 hours. I am not sure if that is right, but 5 hours out of 40 per se seems about right. To me, a 3-hour dinner with a customer will be very revealing.

Time matters… Speaks to quality, don’t you think?

His assumption here is that there’s no meaningful insight to be gained in a 5-minute conversation. He’s also arbitrarily picked 5 hours per week. (Why not 4? Or 2? Or 8?)

My response:

Here’s how we should think about it.

Why are we seeking VOC? What’s the purpose?

At the most fundamental level, in any situation, there are three kinds of customer insights we’re trying to gain:

  • Problem Discovery
  • Problem Hypothesis Testing
  • Solution Hypothesis Testing

There are many techniques to accomplishing these. The specific ones we use depends on the situation.

For problem discovery, a series of 1-on-1 interviews is best. These take time. 45-60 minutes an interview across 10, 20, 50 customers, for example.

For hypothesis testing a broad problem domain, again, 1:1 interviews may be best to start with.

So in this case, I’ll opt for 23 phone conversations of 30-60 mins each, because I know neither email nor a survey nor a 5-min phone conversation will provide me the richness of insight I need.

For solution hypothesis testing, it can vary.

If I’m validating a mockup of a potential solution the customer has never seen before, a 20-60 min interview may be needed.

In all the above situations, I want the richness of the fluidity of the conversation, have an opportunity to ask follow-up questions, and feel the customer’s emotional responses.

But let’s say I’m trying to validate the need or usefulness of a specific feature — i.e., will it or does it solve a specific, previously identified customer problem.

In this case, using an email or an automated tool would enable 23 touches in 5 minutes, and work perfectly. I could do it via phone calls, which would have taken longer, but ultimately would have given me the same quality of insight.

Another example is having weekly meetings with the Sales team.

The meeting doesn’t preclude the opportunity for a Product Manager to get on sales calls and demos. However, there’s great efficiency and value to these meetings, because in 30 mins I get buyer feedback across all our products from 9-10 folks who are making a large number of customer calls every day.

Which technique to use in any given situation depends on the type of VOC one is seeking, the purpose of seeking it, ability to access the customer quickly, the time available to seek and act on it, and of course reasonable judgment.

With respect to allocating time for yourself to obtain VOC, that’s a different thing.

You’re a busy person, so it’s perfectly reasonable you need to figure out how much time to allocate for VOC vs. other tasks.

But that’s solving your problem — your problem of time allocation.

It’s different than the how, what and why of obtaining the VOC itself.

And provides no guarantee of the quality of customer insight that you may gain.

No, I Can’t Give You A Roadmap For Our New Product (Yet)

Cartoon by Roger LathamA fellow product manager that’s working on a new product idea recently wrote to me:

“Common feedback I receive from our our engineers and executives is they don’t have a good grasp of the product vision. They say, “OK, that’s great, we can build that. But where are we going with this if we find the hypothesis to be true? What’s the long term vision for the product?” In essence, they’re asking what’s the end goal in 2-5 years, and if you show me that I’ll have a better sense of the architecture and tools I need to account for.”

This product manager is right at the very initial stages of their product idea, where he still needs to test the problem and solution hypotheses. But he’s already being asked for a long-term product roadmap! Sound familiar?

While the request seems perfectly reasonable, it’s misplaced at such an early stage. The question about architecture and tools seems perfectly reasonable on the surface, but it’s a scale question, and is not the right one to be focusing on before you even know if you’ve identified the right customer problem and have proof that your solution approach is viable to solving that problem. Execs are trying to assess the potential market opportunity, the underlying investment that will be needed, and the speed to achieving ROI. So naturally they want to see the long-term roadmap. Again, perfectly reasonable on the surface, but at such an early stage, you’re likely in no position to be able to answer the question.

Even at the conceptual stage, you likely have a list of potential features in your mind. You could prioritize them using one of the many scorecarding techniques written about by seasoned product practitioners. (See this, this, this, and this, to reference just a few.) These are all very valid techniques written by product folks who really know their stuff.

If you do that, though, you’ll be wasting your time. Creating a product roadmap is predicated on having a coherent product strategy, which is predicated on having a validated understanding of who are your customers, what are their pain points, and whether they’ll find your solution valuable. If you don’t even know if customers will buy your solution, what’s the point in having a roadmap?

So when do you develop a roadmap for a new product? I get this question a lot on my free product help calls, so I thought I’d share my answer here.

For a startup product, the first step is always to identify the customer segment and customer problem. Quickly capture your product vision, formulate your customer, problem and solution hypotheses, and systematically test them. As you go along, you need to identify potential “innovator” customers and early adopters to whom you could deliver your solution — typically you build the product for these folks first. If practicable, test pricing at this stage as well.

Figure what you absolutely must deliver to these folks to solve their #1 problem, and work like hell to deliver it as quickly as possible. All other features get cut from scope and sit in the backlog. Again, with respect to pricing, what the customer is willing to pay to solve for takes clear precedence over anything else.

After delivering this, say, MVP, you need to actively gain feedback from these early customers. You’re using your delivered product to gain deeper insights into the customer’s problem, and you’re trying to understand what you need to improve in the product to (a) get these customers to stick, and (b) attract more new customers.

In addition, now that you have an initial set of engaged customers, you can also try to test their second level set of problems (or discover new ones). Understanding those problems may identify new enhancements/features. You’ll now be armed with a set of improvements, fixes and new ideas that you can put into the backlog.

If you have a sales force, and have armed them to sell your MVP, make sure you’re actively gathering feedback from them as well. Of course, not all their feedback may be feature-related — some may be about testing and evolving your sales messaging and positioning. However, as it relates to feature gaps, you put those into the backlog as well. I pay particular attention to feedback that’s preventing a customer sale.

You’ll have a pretty good backlog at this point, so you can now start building an initial roadmap. Start by prioritizing the backlog based on a reasonable customer-centric set of criteria that also help deliver on your company goals. I typically skew my priorities heavily toward voice of customer (VOC) feedback. While at any stage of the product lifecycle, features should solve tangible customer problems, it’s even more important at this early stage.

I also factor in the company’s strategic goals. For example, if the company’s focus is retention, features that create stickiness may carry more weight; if the focus is growth through customer acquisition, then sellable features may be more important; if it’s revenue through customer penetration, features that drive engagement and up-sells may take priority.

I also make some allowance for operational issues. I may not necessarily have a scale problem (yet), so these type of issues may not take precedence over VOC or driving revenue; however, I don’t want to completely ignore technical debt or reasonable operational fixes.

Once you have a prioritized list, socialize it. (Read this post by Bruce McCarthy on using “shuttle diplomacy” to get buy-in.) For the top priority items on the list, get t-shirt sizing from Engineering, and make a final call to sequence out the items based on customer value vs. LOE. Now you’ve got a validated product in the marketplace with a decent first-pass roadmap that you can build upon.

RIP PRDs. Long Live “Agile Conversations”

Many of my free product help calls are about ways to pursue customer development and gather VOC, bootstrap new product efforts, and apply lean principles to product management activities. I recently had an email Q&A with a fellow PMer in which I shared what’s worked for me. So I decided to post my answers here — of course, your mileage may vary, but perhaps there may be some nuggets that may help you.

Voice of the Customer (VOC)

Besides web analytics, do you have any tools you use to facilitate getting VOC from the market? Customer interviews are great, but my experience is that it can be hard to get this feedback on a continuing iterative basis. Are there tools you use to make sure you have the #1 customer problem identified?

  • For identifying the #1 problem, nothing beats interviews. You need qualitative feedback, especially at the early stages.
  • Solution hypothesis can be also be validated qualitatively via interviews, as well as quantitatively — e.g., watching engagement metrics on a feature.
  • Regardless of the stage of the product, I always dedicate time every week to speak with my customers.
  • For now, we capture this feedback in Google Docs. Works well enough.
  • That said, lots of tools to choose from: ListenLoop, Survey Monkey, Google Forms, UserVoice, and Intercom.io, to name a few.
  • Sometimes plain old email and phone work best!
  • UserTesting.com is an option for usability testing. 5 respondents is good enough.
  • Can also ask for feedback directly within the app itself. Many apps, like Jira and Basecamp, now do this.
  • Which tool you use depends on the type and frequency of the VOC you’re looking for, and the lifecycle stage of your product.

Hypothesis Testing

What do you do to create your hypothesis and metrics, and at what stage in the process? Ash’s model in the Lean Stack works to an extent, but it is focused more on startups as you know.

For startup product, yes, at just about every stage we’re testing hypotheses — see my post on using validated learning for a new product idea. If you’re doing problem validation right before the sprint, it’s too late.

For a launched product, depends on the nature of the hypothesis to be tested. If it’s an optimization type hypothesis — e.g., do customers convert at a higher rate with copy A or copy B — A/B testing or engagement metrics may work fine. Tools like Optimizely can help.

If it’s a more pivot vs. persevere type test, then it depends on the specific component of your product strategy or business model you’re testing. For example, if you’re reliant on lead gen to fuel inside sales, testing sales pipeline metrics, product positioning and sales commissions becomes important. If you’re an e-commerce play reliant on SEO/SEM, those are the metrics to focus on.

Problem/Solution Interviews

I have recently tried to combine problem/solution interviews into one interview, because l found that at the beginning of the Solution Fit interview I could test to make sure that I had the #1 problem nailed. As you stated in a response to one of my comments on your blog, you find that with an existing customer base you often have a good idea of what the #1 problem is, and that you can often just verify this in the Solution Interview.

I’ve done both: combined and separate. Pure problem interviews are great for immersing yourself into your customer’s world — what they do today, where they feel the pain, and how they articulate it. However, it is true that sometimes you need to get them to react to something to give some structure to your discovery.

There’s also an aspect of knowing your customer. If it’s a new product to existing customers, I may already have a pretty good idea of their pain points, and how well they articulate their problems. So I may combine the problem and solution interviews. If it’s a new product to new customers with whom I’m less familiar, I may prefer a pure problem interview to allow me to understand the customers better.

Ultimately, just need to use good judgment based on the nature of the problem, the solution you’re envisioning, and your target customer.

Requirements

As you preach, long MRD/PRD’s make no sense. However, there is some need to provide our business analyst with some form of requirement. What do you do in these cases? I have a Feature Requirements doc I created, but I sometimes feel it is overkill. What would you recommend?

  • We don’t write MRDs, PRDs, or any sort of traditional functional spec. It’s a total waste of time.
  • If we have time, budget and bandwidth, we’ll always get a Designer to create the screens before getting it to Engineering. Doing otherwise is a waste of Engineering’s time. Only caveat is I keep my Engineering Head / Chief Architect informed and involved.
  • Since the Designer is the recipient of the stories, we can write them at a fairly high level. We don’t get hung up too much on granular acceptance criteria — the use case, user goal or job story is much more important at this stage.
  • As such, at times we’ve provided just a 1-pager with bullets. Because design is iterative, we lean more heavily on interactive ongoing conversations than paper.
  • If we don’t have time, budget or bandwidth for a designer, PM just hacks the screens — Balsamiq, ppt, whatever. Not ideal, but sometimes you just have to make do. I’ve literally sent a photo of a whiteboard doodle, and written the story around it.
  • As much as possible, for major new features or flows, we will do customer validation. Yep: phone interviews with screen shares. 5 may be good enough.
  • We don’t have a Business Analyst, so PM writes the stories directly, including me. It’s not hard, and removes a middle man. Not saying a BA/BSA is never needed — just saying in our case we haven’t had the need for one, and have managed fine.
  • When ready to provide the stories to Engineering, we do write more granular level stories. Granularity is determined by the detail put into the screens. Let’s say we had a designer mockup every detail — every click, button placement, font, color, and even copy —then it’s just easier to add the mockup as support documentation and point to it in the acceptance criteria. If the design was more high-level, like a ppt hack or my silly whiteboard doodle, naturally I need to provide more specificity.
  • We use Aha.io to capture ideas, convert them to features, write stories, attach documentation, do prioritization, and map out an executable roadmap. It has some super cool features:
    • It will spit out a req doc from the stories you write. This is helpful if you’re using a 3rd party dev firm and need to provide them a written doc during the initial planning stages. So we no longer need to use MS Word.
    • It has an awesome Jira integration feature, where I literally click a button and boom, everything is automatically placed in the Jira backlog.
    • It allows me to publish out status on our roadmap execution to senior execs. This is extremely helpful, as it gets me away from PowerPoint and Excel crap.

Ultimately what really matters is joint understanding between PM and Engineering. If there’s a good relationship, both sides can come to an agreement on how the reqs should be delivered. I’ve found regardless of how the reqs are documented, ongoing conversation between PM and Engineering is the key.

Want to learn more? Faced with similar challenges? Just pick a slot on my FREE product help time!

A 5-Step Roadmap To Validate Your Product Idea

Here’s a scenario:

Top Exec at your company comes to you and says, “Yesterday, I was talking to Big Industry Player and they mentioned how they have Shiny Object. I think we should have Shiny Object too. How fast can we get it done?”

Sound familiar?

At last weekend’s ProductCamp DC event, my co-founder and I hosted a session called “Tales From The Product Frontlines”. Our first topic was about this very scenario, and it so energized the participants that it took up 30 of the 45 minutes we had been allotted!

During the session, we asked product people questions like:

  • What do you do now to vet new ideas, whether your own or from some other source?
  • How is that working?

Most folks talked about having some sort of governance structure, such as an Executive Steering Committee to vet new ideas based on some established criteria. Many talked about the need to create a business case, and some advocated that Product Management is best suited to do that, regardless of where the idea came from. Yet, after the session, every person I spoke with told me they felt writing a business case was a total waste of time.

Why is this? Because the old ways just don’t work.

Pragmatic Marketing’s 2013 survey revealed that product managers spend over a month’s worth of time writing business cases. These business cases are filled with highly assumptive 3- or 5-year projections that are used to support significant investment asks. It’s no wonder we hate this — we’re staking our professional credibility on these unvalidated assumptions!

The problem is we were never taught a systematic method by which to obtain the crucial information needed to inform a business case.

So what’s the solution?

Let me pause here to say if you’re hoping I have a magic secret for quickly validating a product idea, or if you’re totally married to writing business cases or MRDs, then stop. This post isn’t for you, because:

  • It’s different and requires you to THINK.
  • It’s hard work.
  • It can take some time to get results.

But it works. I’m writing for the 10% who (1) realize I’m telling the truth (that the old ways just don’t work), and (2) are willing to try something different.

(Thanks, Kevin Dewalt, for putting this so well, and forgiving me a little plagiarism!)

The solution is validated learning

Bottom line is spending time writing a big document is a colossal waste of time. Instead, focus on validated learning.

Because any new product idea is based on assumptions, those assumptions need to be validated. This can be achieved by formulating testable falsifiable hypotheses around the riskiest assumptions, and rigorously testing these hypotheses.

The process of validation can be outlined in 5 steps. Each step generally follows this meta-pattern:

  • Formulate hypothesis.
  • Test hypothesis.
  • Analyze results and learnings.
  • Decide to pivot or persevere.
  • Repeat.

In full disclosure, I’ve used these this process to validate ideas for software products, but I imagine it could be adapted for any product concept.

1. Write down your customer hypothesis.

Most folks typically start with the solution first. So this step forces you to take a giant step back and think very deliberately about your customer. If you’re pursuing a new product idea in an already existing business, this could be your existing customer base or a segment of it. If you’re a true startup, you may have some work to do here.

Note, by customer I mean the individual who will buy your product. Even in B2B, you need to think about the specific individual or set of individuals to whom you will need to sell your solution. That’s your customer.

2. Write down your problem hypothesis.

What problems does your idea solve for the customer? One way to do this is to think about the goal or job the customer is trying to accomplish. For example: “I believe [customer] has a problem achieving [goal].” Or: “I believe [customer] is trying to accomplish [job], because [desired benefit].”

I typically use the Product CanvasTM to do this, as it allows me in a focused manner to break down the problem domain into discrete problems, and then formulate hypotheses around what I believe to be the top problems that my solution absolutely has to solve for first.

3. Validate your customer/problem hypothesis.

Now it’s time to validate your hypotheses. You do this by talking to folks you believe meet your target customer demographic. Be sure to define a minimum success criteria, which is the minimum amount of data you will need from the test to justify investing more time, effort or resources into proceeding with the idea.

When you’ve met your minimum success criteria, analyze your data, and decide whether to Pivot or Persevere. A pivot is a fundamental change in direction of your business model or product strategy. At this early stage, you could expect a pivot in terms of a change to your target problems, your target customer, or both. This may mean going back to step 1 or 2. However, if the results of your test prove your customer/problem hypothesis, you may decide to persevere, and move on to step 4.

4. Validate problem/solution fit.

Now that you’ve validated your customer/problem fit, you need to validate whether your idea is a potentially viable solution to the customer’s problem.

There are many ways to go about this, but nothing really beats creating a visual representation of your envisioned solution in the form of a wireframe or mockup. To keep things simple and minimize work, I look to design a representational screen or flow for each discrete problem identified on my Product Canvas and validated via the previous steps.

The primary goal of this stage is to garner early customers who endorse your solution vision, and would be willing to use (and ideally pay for) an early version of the product. You’re also looking for directional feedback to identify the “right” handful of features to build for these early customers to prioritize your product development.

Formulate hypotheses around your screens, define your minimum success criteria, then reach back out to the customers you had interviewed earlier and demo the screens to them. Also try to mix in some new folks who fit your target customer demographic.

When done, just like you did at the end of step 3, analyze your data and decide whether to Pivot or Persevere. At this stage, you may pivot on the solution, the problem or even the customer. Or, if you’ve validated your hypothesis, you may have problem/solution fit, and can move on to step 5.

5. Validate your solution via an MVP.

There are many misconceptions about what constitutes an MVP, and I’ve written about these before. In short, an MVP is an actual product that attempts to deliver real value to customers. It’s “minimum” in the sense that it’s an attempt to deliver the absolute necessary set of features or capabilities needed to solve the customer’s problem for which the customer will pay. A primary outcome of the previous step is being able to understand your customers’ problems at a granular level, which helps prioritize the initial set of features to build. This drives the definition of your MVP.

Once again, formulate a set of testable hypotheses to ensure you’re continuing to drive your product development based on validated learning. Depending on the complexities of the problem and solution, and the nature of my target customer, I may opt to first demo the MVP before actually delivering it. The results of your MVP test will again determine whether to persevere or pivot.

If you’ve got this far, you’ve validated critical components of your product idea. It doesn’t mean your idea is guaranteed to succeed, but you will have gained a far better understanding of the market opportunity, allowing for a far less assumptive and much more robust business case for your new product idea. In fact, this is exactly the process you’d follow for a more bootstrapped approach for a new product idea.

Need someone to talk to about pursuing a new product idea? Just pick a slot on my FREE product help time, and I’ll be happy to chat!

Using Customer Development To Create The Business Case For Your New Product

Many of my product help calls are from folks frustrated with being able to pursue a new product in an existing company. They complain about how difficult it is to secure resources and garner internal stakeholder buy-in.

If you find yourself in this position, congratulations! As painful and frustrating as it is, many successful product people I’ve met have gone through exactly what you’re experiencing — including me!

The problem is the way we’ve been taught to pursue this — to first write a business case, business plan or MRD — just doesn’t work. The fact is, people think writing a business case is a waste of time and hate it.

And no where are we taught how to cultivate stakeholder support. Like it or not, every project in an existing company, regardless of the size of the company, needs an internal champion or sponsor. Lack of stakeholder buy-in can kill any product endeavor not matter how good your product idea may be.

So it’s no surprise really that product people are frustrated.

So here’s a new process I’ve tried recently that worked much better for me:

Bootstrapping My Product Using Validated Learning Milestones

That’s right, I bootstrapped it. I deferred asking for major dollars and resources until I absolutely needed to. Here’s what I did:

  1. I quickly sketched out my product strategy. The Product Canvas works perfectly for this. No wasting time writing a multi-page document no one is going to read.
  2. I decomposed the product strategy into critical learning milestones meant to answer the most important questions in my product strategy:
    • How does our target customer describe the problem?
    • How are they solving it today?
    • Why is that solution not working for them? In other words, why is the problem still a pain for them?
    • How can we know before we invest a lot in development, sales and marketing that the solution we’re thinking of building really solves the problem?
    • How quickly can we get our first customer?
    • What are the most important features we need to have in our go-to-market product?
  3. I figured out what’s the least amount of work I need to do to maximize my learning for each milestone.
  4. I broke down my investment need into these milestones, showing how ROI could be tangibly achieved based on measurable results.

Here’s what the investment plan looked like:

validation_workflow

So where’s the bootstrapping part?

Well, in the past, I would have asked to spend money on 3rd party market research (four to five figures), a design agency to craft the user experience (five to — I’m ashamed to admit — six figures), a usability study (five figures), and a large development team (many figures). This would be costly and take a long time before I would have delivered the product to a single customer. And it’s a tough business case to make.

Instead, because I had broken down the plan into these learning milestones, I was able to easily accomplish the first two milestones by spending little to no money at all. The first is simply my time, so requires no money. To validate our solution hypotheses, I used Balsamiq to sketch a handful of the key screens of our solution. Total cost was $79 for the tool and my time.

When we were ready to design the user experience, since we didn’t have an in-house designer, we commissioned a cracker-jack freelance designer — way cheaper than hiring an expensive design agency, and way faster. It got the job done. If you happen to have an in-house designer, even better, since your investment “ask” may only be some of their time.

This is classic bootstrapping — using the resources you have at your disposal for as long as you can to create traction.

This approach not only allowed me to conserve precious funds and resources, but also allowed me to be less assumptive and more data-driven in identifying my investment ask at subsequent stages. It also enabled me to not only build early traction with customers, but also have them help me define the minimum feature set we’d need to develop to go to market — labeled as the Minimum Sellable Product (MSP) in the picture above.

Here are the benefits that resulted:

  • Instead of writing a massive business case based largely on guesswork, I needed only to sell a bunch of mini-business cases. Way quicker and easier to do.
  • Each mini-business case was informed by the learnings from the previous stage, making each subsequent mini-business case better informed, more robust, and an easier sell.
  • The product strategy was informed by real market insights. (What a product manager needs to do anyway!)
  • I had a customer driven product roadmap that was tough for anyone to dispute as it was informed directly by tangible customer insights, which defined what went in our MVP vs. MSP vs. roadmap vs. nice-to-have.
  • This enabled our product development efforts to be more focused, as I had all the ammunition I needed to fend off arbitrary new feature requests that risked derailing our product development.
  • Because of our “co-innovation” approach with our customers, we were able to get “earlyvangelists” that we are leveraging to generate momentum for our broader market launch. Customer Development in concert with Product Development!
  • All of this made it much easier for me to garner, maintain and accelerate buy-in from my internal stakeholders, because:
    1. My plan showed a clear milestone-based investment plan with the ROI to be gained at each phase.
    2. Smaller continual investments are easier to digest and support than a large upfront one.
    3. Each investment stage was grounded in real customer data, increasing confidence in pursuing the product.
    4. My stakeholders felt involved in the process, as I made sure to keep them informed and provide them an opportunity to provide feedback.
    5. This, in turn, kept me one step ahead of any potential concerns they may have had, and I could make sure to address them at a future stage.

Need someone to talk to about pursuing a new product at your company? Just pick a slot on my FREE product help time, and I’ll be happy to chat!

Note: Customer/Problem Fit and Problem/Solution Fit were first defined by Ash Maurya in his book “Running Lean”. Minimum Viable Product was coined by Eric Ries. The first I had come across the term Minimum Sellable Product was in this Slideshare presentation.

How A Rusting Giant Can Act More Like A Startup

This is a Q&A with Trevor Owens, Founder of Javelin, by Adam L. Penenberg originally published on PandoDaily, and re-printed here with Trevor’s permission.

Why should big companies emulate startups?

Back in the day, everyone wanted to work at a place like IBM. Today corporations are viewed as stodgy. Many of us don’t know what they do anymore and even if we did, we probably wouldn’t care. These bloated companies with their thousands of workers trapped within walls of bureaucracies aren’t growing anymore. In fact, their markets are shrinking.

The time between the birth, growth, and death of a large enterprise has shrunk dramatically over the years. Of the companies listed on the Fortune 500 in 1955, nearly 87 percent of them have either gone bankrupt, merged, reverted to private ownership, or lost enough gross revenue to be delisted. A study of the S&P 500, which ranks companies by market cap, found the average age of a business on the list was 61 years in 1958 but only 18 years in 2012. In the past, being big was in itself a defensible position. Now it’s not.

Contrast that with the frenetic growth and buzz surrounding successful startups. Instagram employed just 12 people when it sold for $1 billion. Snapchat had about 30 people when Facebook offered to snatch it up $3 billion. Whatsapp employed 50 or 60 people when it sold for $19 billion.

Big companies see this, and feel the cultural pull away from them. They’re starved for growth. If they want to compete, they have to become more like startups. Otherwise they’re in jeopardy of disappearing all together.

Why do big companies have trouble innovating?

When a company gets big, bureaucracy is layered throughout. In some ways it’s a necessary part of growth. The reason it exists is so the company doesn’t fall apart. The more people you have working for you, the more you need to manage them to ensure they get the support they need to do their jobs. Then you have whole divisions that exist simply to produce and sell, and their heads aren’t interested in new ideas, products, or ways to do things that could interfere with their bottom line, because that’s how they’re judged and compensated.

Couple all that with the main goal of a company, which is to serve existing customers. That’s where the resources go. Corporations offer an environment of execution and maintenance but not innovation, and rely on good management to target their best customers and deliver better products. That’s fine when they’ve identified and mastered their markets, but they get disrupted when a new entrant comes along that can deliver a good enough product at much lower cost of higher convenience. New entrants target low-value customers then quickly climb the value chain with a better cost structure. Think Netflix versus Blockbuster or Napster invading the recording industry.

Part of issue is there’s no management philosophy built around how to innovate within a large enterprise. With new companies we have the Lean Startup Method, which offers a framework for constantly improving a product to find the best product-market fit before you actually go into production or invest gobs of money in creating any infrastructure. This is the first time we’ve had a repeatable process. But there is no analog for large companies. They have to develop some basic structures just to deploy lean startup methods.

How are some big companies innovating like startups?

There are two parts to innovating like a startup. One is generating a flow of high-quality (i.e. validated) ideas. We call this “innovation flow” — similar to the idea of deal flow for venture capitalists. If a VC doesn’t have good deal flow he won’t get returns.  The other is the need to create a structure to incubate these ideas called an “innovation colony.”

Intuit does the first part well. It kind of copied our lean startup workshop and scaled it throughout the company. After employees have been trained in lean startup methods and know how to validate ideas, they can take advantage of unstructured time (also known as 10 percent time) to work on any project they want to validate that can potentially become a successful new product. If they find they have something they can go to their boss for funding, and this has led to some viable products, including Sparkrent.

Facebook is famous for hackathons. That’s where the Timeline was first imagined. Employees can work on anything that relates to the company’s products and deliver a down-and-dirty prototype during a 24-hour hackathon. Companies like Nordstrom are becoming sophisticated at lean startup methods. It runs weeklong experiments. One from 2011 involved an iPad app that helps users choose eyeglass frames and another addressed the physical design of its retail stores.

Companies also acquire startups to “buy growth,” although few buy at the right time. One that did was Twitter, which acquired Vine before it launched, left it alone to carry on its mission without interference, and it ended up a great acquisition. Vine clearly had product/market fit right out of the gate.

What about skunkworks, innovation labs, and intrapreneur programs?

For large companies there are three traditional innovation structures:

First, there’s skunkworks, when you hire a bunch of smart people to work on pie-in-the-sky technologies. Motorola, for example, hired away a former head of DARPA to run its skunkworks. It only works on highly technical products with low market risk — like a faster jet plane or Amazon Web Services. It’s not good for developing, say, an app like The Daily and it won’t help you find a market or determine product-market fit.

Then there are innovation labs. Perhaps the best known was Xerox Parc, which was the original Innovation Lab. It came up with brilliant ideas but failed to commercialize them — until Steve Jobs came along and borrowed (some say stole) them. Innovation labs that focus on innovative technologies are known to struggle with commercialization.

Finally, you have intrapreneur programs, which are the latest fad: a four- or eight-week program where employees take time off, explore some ideas and a product, and have to sell it to a business unit within the company.  The issue comes back to the incentives inherent in successful business units. They resist ideas they didn’t come up with, no matter how big their potential. They favor incremental innovation that won’t cannibalize their own sales over something that could change their industry for the better.

As a corollary you can have something we recommend: innovation colonies. This is a way for companies to create a fund to invest in ideas their employees have. To participate, though, the employee has to give up the security of their jobs in exchange for equity in the venture. Microsoft, Kaplan, Nike, Barclays, and Disney are just some of the companies utilizing innovation colonies.

Here’s how they work: Employees pitch their ideas, which have been validated, get funding, and own a majority of the equity in these products in the seed stage. They work with other entrepreneurs and the company offers advisement, mentoring and other resources. They seek to develop products, take them to market, and if they gain any traction they can raise a series A with outside investors. They run the company without interference from the Mother ship. In the end, the big company can offer to buy their startups back. The magic is that the entrepreneurs are incentivized to build a real business.

Is it a good idea to offer equity stakes within corporate environments?

Oh, yes. In fact, we advocate for employees to get equity on their projects. Let me emphasize that I mean equity in the product, not the company. Equity attracts the best people because entrepreneurs are motivated by achievement and autonomy and are willing to take less in salary in exchange for more upside in their ideas. Of course, they want to see millions from their products, if they’re successful, but it’s not just about money; it’s what it represents. It’s about being recognized for your achievements. Face it: you have to be a little crazy to be an entrepreneur. This is the whole point of the innovation colony structure.

If you don’t give employees who are entrepreneurially minded equity in their projects they’ll leave to start their own companies. This happens even at innovation-friendly environments like Google: Ev Wiliams (Twitter), Kevin Systrom (Instagram), Dennis Crowley (Foursquare) all left to launch their own ventures. It’s unfortunate that Google doesn’t share in any of the billions they’ve created.

Not only do you want to hire the best and brightest, you want them to stick around and create the kinds of innovative products and services that will also ensure your company sticks around for the long term. Some large companies make the mistake of addressing a problem by simply throwing 15 developers at a problem thinking it will lead to something. Instead, great ideas come from all over an organization and may even seem like bad ideas at first until you validate them.

Once a company realizes this, anything is possible.

Trevor Owens is a thought leader on Lean Startup. He is the Founder of Javelin, a provider of tools and services to learn, launch and track new business ideas, and Lean Startup Machine, a three-day workshop that teaches entrepreneurs and innovators how to build startup products. He has a new book called The Lean Enterprise that talks about how to bring the startup mindset to larger organizations.

Yes, Startup Products Can Take A Village

Thomas Pichon is the Founder of The Collaborative Startup. He advocates building a community to gain traction for a startup, and I thought the advice could equally apply to an “internal” startup. The article below is re-posted with his permission from his free e-course.

By Thomas Pichon

I am helping an entrepreneur build a yoga retreat, and I asked her how she was going to build her project. She said:

“I guess I’m going to concretely build the service, which means finding where we’re going to host the retreat, build the program, etc… Then, I’ll try to advertise it.”

I used to build products with this kind of strategy for years. Results have never been extraordinary. However, I have discovered one which brought me much more success:

  1. Build your community. Share helpful content related to the service you want to provide in order to attract people.
  2. Ask them what is their biggest frustration. Build a service around this problem.
  3. Get pre-orders. Start collecting credit card numbers before you have built the service. If you have created trust with your community by providing helpful content from day 1, you will see that this step is much easier than it looks now.

Hope these lines help you understand how to start your business. Do not build your product, then try to sell it. Sell it, then build it. And the better way to sell it before having the product ready is by building trust within a community.

So start now! Write helpful content about your topic in order to start building trust! Share it where your target audience hangs out online.

If you need any advice on this topic, or more generally about startups, you can schedule a call with me anytime, or ask your questions on my forum.

Thomas Pichon is the Founder of The Collaborative Startup, an innovative initiative designed to help entrepreneurs by leveraging the power of community development, Lean Startup and crowdsourcing.

The Dirty Dozen Product Roadmap Roadblocks

In my last post on defining an MVP in corporate innovation, I talked about how best practices in garnering stakeholder buy-in for product roadmaps espoused by Bruce McCarthy can be used as a framework for the same when defining an MVP in an “internal” startup product. Here, with permission, is a re-post of his excellent post on the the “Dirty Dozen” product roadmap roadblocks, and in a way, they seem applicable to internal startup products as well.

By Bruce McCarthy

A good product roadmap is one of the most important and influential documents an organization can develop, publish and continuously update. It’s the one document that steers the entire organization in delivering on the company strategy.

It’s key to success, and yet many organizations struggle to produce effective roadmaps. In fact, many organizations don’t create one, even to publish internally. Or they do, but it is simply a collection of unrelated features and dates.

What Is A Product Roadmap?

A roadmap is your vision for how a product (or product line) will help achieve your organization’s strategic goals. In that sense, it is literally a map of the steps involved in getting your business where you want it to go. To make it even more concrete, I also like to think of a product roadmap as a timeline view of your priorities.

A good roadmap inspires. It inspires buy-in from executives, inspires confidence from customers and salespeople, and inspires development teams to produce the groundbreaking products that drive significant growth.

A good roadmap keeps your organization on course toward its destination. Stating what you will do and when makes it easy to judge when you fall behind schedule or get detoured by good ideas that just don’t fit your strategic vision.

The Dirty Dozen

In my experience, though, there are some specific areas where companies commonly break down in developing roadmaps, hitting roadblocks that often keep them from getting where they want to go. I call these roadmap roadblocks the “Dirty Dozen.”

1. No Strategic Goals

If a roadmap is the path toward your goals, you obviously need to set those goals before you start. Yet many companies fail to sit down and explicitly describe the destination they are driving toward.

Is your product roadmap aligned with your strategic goals? Have a conversation with your CEO or another exec in the know. It may clarify a lot of your prioritization dilemmas.

2. Focusing on Features

A lot of roadmaps are just a list of features in upcoming releases. This is meaningless to most people outside of the development team. A roadmap should make it obvious how things will improve for your customers, organization or shareholders. Like any good sales pitch, it should focus on delivering value.

Look at your roadmap from the point of view of a board member or a customer. Would they see their interests reflected?

3. Inside-Out Thinking

Focusing on features can be a symptom of failing to understand your market. Yes, priorities should be driven by internal goals, but those goals must also respond to market reality.

Ask yourself whether your roadmap priorities are driven by the needs of the people and organizations you intend to serve. Strive to bring that message from the outside in.

4. One Size Fits All

You probably serve more than one market segment. When you are talking to customers or partners in one segment, the roadmap you show should focus on how you will address their needs.

Make sure your roadmap is not one-size-fits-all. If a customer sees their interests in only 1 of the next 6 releases, they’ll get the message that you are not focused on them.

5. Trying Too Hard to Please

That said, many roadmaps are simply lists of customer requests prioritized by number (or size) of customers requesting or voting for the feature. This may help with retention for a while, but will not drive your company into new markets or to invent anything new.

Rather than just taking requests, listening for unsolved problems in your market (and doing something about them) is the best way to avoid a roadmap that’s really just a popularity contest.

6. Playing Catch-up

It’s often a mistake to focus on matching your competition feature-for-feature. All this does is commoditize your market. Instead, focus on creating unique value by developing solutions your competition can’t easily duplicate.

How many items on your roadmap are “me too” features designed to close perceived competitive gaps? How many of those have actually lost you business?

7. Not Getting Buy-in

The best-conceived roadmap won’t get you where you need to go if you can’t get anyone else to come along for the ride. You’ve got to get your development, sales, marketing, finance and other stakeholders involved early so it becomes their plan, not just yours.

If people use words like “intellectual,” “cerebral,” “theoretical,” or “ivory tower” to describe you or your work, this is code for lack of buy-in.

8. Prioritizing on Instinct

Good product people develop good instincts for their market. As a company grows, though, it’s hard to get the buy-in you need from all players based just on your instincts.

Can you tie everything on your roadmap back to your strategic goals? Can you show the ROI calculations that put priority 1 ahead of priority 2? A little data settles a lot of arguments.

9. Being Too Agile

Agile was developed as a response to lack of consistent direction from business execs. That doesn’t mean it’s incompatible with good direction. Yet many companies fear to map out a course thinking it’s not allowed in Agile.

Don’t let being agile become an excuse for indecision. You may choose to adjust course down the road, but you’ll move a lot faster if you first take your best guess at a destination.

10. Being Too Secretive

Some organizations have a roadmap but shy away from sharing it with anyone. It might be fear of revenue recognition issues, lack of confidence in the company’s direction, or just not wanting to look foolish if things change.

A good roadmap is not a contract. It can and should be designed as a statement of direction and intent, but customers and investors expect you to accept and act on feedback from the market. They expect your roadmap to change, so stop worrying.

11. No Buffer

One reason an organization might be reluctant to share is if their roadmap is too detailed. A roadmap consisting of 40 bulleted features in each of 10 precisely-dated releases is impossible to read, and can really constrain your options for adjusting course down the road.

Your roadmap should consist of problem-solving themes and broad time-frames. This gives you the leeway to cut or defer a specific feature without risking on-time arrival at your destination.

12. Over- or Underestimating

ROI is a critical consideration in prioritization, yet many product teams make the mistake of setting business priorities without considering development costs. Conversely, some teams spend months estimating every possible product initiative without first considering which are likely to be worth the time.

Approach your technical partner for a quick, high-level estimate of the work involved in your 10 most wanted. What if #4 turns out to be trivially easy compared to the 3 ahead of it? Wouldn’t you like to know that up front?

AN INVITATION

If your organization’s progress toward its strategic goals is slowed by any of these roadmap roadblocks, feel free to set up a time to chat with me during my free office hours. You may also be interested my hugely popular roadmapping presentation from ProductCamp Boston, or in Reqqsthe smart roadmap tool for product people.

Use your product powers for good.

Bruce McCarthy is a serial entrepreneur, 20-year product person, and sought-after speaker on roadmapping and prioritization. He is Founder and Chief Product Person for UpUp Labs, where he and his team are at work on Reqqs, the smart roadmap tool for product people.

Original article can be found here.

For Corporate Innovation, Lean Startup Is Not Enough To Define Your MVP

One of the biggest challenges product innovators in established companies face in defining an MVP is getting buy-in from internal stakeholders. Be they senior executives, peers, other departments, partners, or even your boss, corporate product innovators have multiple constituents to manage. Somehow, you have to make everyone feel a part of the process without letting them run over you and having your MVP be destroyed by feature bloat right at the definition stage.

This is an area I’ve not seen the Lean Startup movement address. So let’s do that here. The way I’ve done it is by fusing Lean Startup methods with Product Management practices — specifically, by leveraging a process every Product Manager knows: roadmap prioritization.

My friend, Bruce McCarthy, has talked about the 5 pillars of roadmaps, the first 3 of which are:

  1. Setting strategic goals
  2. Objective prioritization
  3. Shuttle diplomacy

These same pillars can be used for defining an MVP and getting stakeholder buy-in.

Setting Strategic Goals

The first step is to capture your product strategy. I wrote about how you can do this quickly using the Product CanvasTM.

What’s great about the Product Canvas is it allows you to document your vision in a simple, portable and sharable way. The trick is to be concise. The intent isn’t to capture every nuance of the customer’s problems, nor detailed requirements. Just stick to the top 3-5 problems and the top 3-5 key elements of your solution.

This forces sharpness not only in your thinking, but also in your communication with stakeholders. This, in turn, encourages more constructive feedback, which is what you really need at this stage.

Objective Prioritization

You’ve probably received a lot of internal input (solicited and unsolicited) on features for your product. Most have probably been articulated as “must-have’s” for one reason or another. Of course, you know that most of them are probably not really needed at this early stage, certainly not for an MVP.

To quote from the book Getting Real by 37signals: “Make features work hard to be implemented. Each feature must prove itself.” For an MVP, each feature must be tied to tangibly solving a top customer problem.

Bruce discusses using a scorecard type system to objectively prioritize features for product roadmapping — in particular, assigning a value metric for a feature’s contribution toward the product’s business goals, and balancing it against a level-of-effort (LOE) metric. The exercise can easily be done in a spreadsheet or Reqqs, an excellent roadmapping tool he’s developing.

A similar approach can be used to prioritize the features for your MVP:

1. Rank each Problem documented in your Product Canvas in terms of your understanding of what is the customer’s top-most problem to be solved, followed by the second, etc.

2. Map Solution elements to Problems. These may not necessarily be one-to-one, as sometimes multiple elements of your Solution may work together to solve a particular customer problem.

3. For each Solution element, identify if it’s a “must-have” for your MVP. Solution elements meant to solve customer Problem #1 are automatically must-have’s. The trick is in making the determination for the remaining Problem/Solution mixes.

4. Identify all features for each Solution element. If you already have a list of feature ideas, this becomes more of a mapping exercise. The net result is every feature idea will be mapped directly back to a specific Problem, which is awesome.

5. Mark each feature as “In MVP” or not. Be ruthless in asking if a feature really, really needs to be part of the MVP. (Tip: not every feature under a “must-have” Solution element necessarily needs to be “In MVP”.)

6. “T-shirt size” the LOE for each feature, if practicable. Just L/M/S at this point. A quick conversation with your engineering lead can give you this.

Like with roadmap prioritization, this entire exercise can also be done via a simple spreadsheet. Here’s a template I use that you can freely download.

The beauty of the spreadsheet is it brings into sharp focus a particular feature’s contribution toward solving customers’ primary problems. And an MVP must attempt to do exactly that.

Shuttle Diplomacy

To paraphrase Bruce from p26 of his presentation, this is probably the most important part of the process — you need to get buy-in from your key stakeholders for your product strategy and MVP definition to be approved and “stick over time”. Bruce shares some excellent tips on how to do this on pp26-30. You need to do the same with your Product Canvas, and then with your MVP definition spreadsheet.

When you practice shuttle diplomacy:

“A magical thing happens. ‘Your’ plan becomes their plan too. This makes [review and approval] more of a formality, because everyone has had a hand in putting together the plan.”

To be clear, you’re not looking for “decision by committee”. As the product owner, you’ll still be looked upon as the final decision maker (remember to stand your ground), but you’re actively trying to bring others along by encouraging input and providing visibility.

Lean Startup purists may vomit at this, but that ignores the realities of getting things done in the corporate world. As Henry Chesbrough writes, “You have to fight — and win — on two fronts (both outside and inside), in order to succeed in corporate venturing.” This means corporate innovators “must work to retain support over time as conflicts arise (which they will).”

This means Stakeholder Development. And that requires shuttle diplomacy.

Here again is the link to download my MVP definition template. Let me know what you think!