Category Archives: Enterprise

The secret ingredient to getting product innovation done

So you’ve probably heard of “earlyvangelists”.

(No? Read this post by Steve Blank, who coined the term.)

In Lean Startup circles, we hear a lot about finding this special breed of customers. Why?

Because they’re the ones willing to make the initial bet on the startup. They’ve bought into the startup’s vision and potential. They’re not just buying a version of the product, but the entire vision of the startup. This is what keeps them committed even if the startup screws up a few times.

They are the true visionary customers talked about in the technology adoption lifecycle.

So a lot of focus is put in identifying, finding and nurturing these earlyvangelists in the form of testing customer and problem hypotheses, testing solution hypotheses, finding problem/solution fit, creating an MVP, and getting true customer validation by finding a handful of customers who are actually willing to pay you for your solution — the “earlyvangelists”.

Now, juxtapose this with traditional product management.

When I started out in product management, I was introduced to the technology adoption lifecycle. I read about it in books. People talked about it in conferences. “You must find those visionary customers and early adopters,” experts said in their presentations.Cool.

Cool.

Problem was: no one taught me how to get these magical customers.

Business school didn’t teach me how to get earlyvangelists.

Product management didn’t teach me how to get earlyvangelists.

Instead, what I was told was to develop a business case. Write an MRD. Create a business plan.

Business school told me I was supposed to do this. Smart consultants and well-meaning senior executives and mentors reinforced this. Elaborate PMO processes required this.

Want resources for your product idea? Show us your business case.

So what’s wrong with that? On the surface, it made sense. Unlike a startup, which is searching for a sustainable business model, a company is executing an existing business model.

On the surface, it made sense. Unlike a startup, which is searching for a sustainable business model, a company is executing an existing business model.

Shareholder returns, customer value, and employee paychecks depend on the successful execution of this business model.

So the company needs to evaluate its investments in terms of risk to this business model. A company needs to know whether to dedicate its resources to project A or B. To do that, it needs to know which has the better payoff.

Good intentions.

But here’s what actually happened.

Product managers began spending loads of time writing multi-page MRDs, crafting business case slideware, and crunching through multi-year financial “projections”. These documents were filled with unvalidated assumptions or HiPPO driven convictions.

“How the heck can I figure out whether customers will buy the product before it even exists?” they’d ask. “How can I figure out how much money it will make when no customer has bought it yet?”

The product manager would torture the spreadsheet, try and convince finance of adoption rates and growth trajectories based on mere guesses, and go to Engineering/IT for estimates.

“You need to give me requirements,” Engineering would say. “If they’re not documented, there’s no way I can give you estimates.”

So the product manager would then start writing an MRD / PRD / BRD / <stick your 3-letter acronym here>. Ah, the joy…

And under pressure to get “accurate” estimates, they’d pack in as much detail as possible, essentially guessing at the features and functionality that would be needed.

And every minute the product manager spent preparing the business case, writing the MRD/PRD or torturing the spreadsheet was valuable time not spent with customers.

So it’s no surprise that in a recent survey filled out by over 40 product managers who enrolled in my online course, Idea To Revenue Masterclass, they listed the following as their biggest product innovation challenges:

#1 Biggest Innovation Challenge: Testing product ideas without having a product.

Meaning testing with both customers and internally within their organizations. They need ways to test their understanding of the market, as well as evaluate the revenue potential for a product opportunity, but without having a product already.

“My number one product management challenge is creating business requirement documents on new products and demonstrating a return on investment for 1/3/5 years without releasing the product.” — survey response

#2 Biggest Innovation Challenge: Alignment, buy-in and communication.

How many people does it take to change a lightbulb?

(Or maybe the question is: how many people does it take to get approval to change the lightbulb? Ha!)

This challenge is a close second to the first. Product innovators are challenged with communicating product strategy to get buy-in, getting executive support for their product plans, aligning teams within the company to support new products, and managing communication across multiple stakeholders.

“In a growing organization, with lots of ‘people of interest’, communicating what you are building and why is a huge challenge.” — survey response

In a blog post titled, Why Internal Ventures are Different from External Startups, Henry Chesbrough argued:

The internal venture must fight on a second front at the same time within the corporation. That second fight must obtain the permissions, protection, resources, etc. needed to launch the venture initiative, and then must work to retain that support over time as conflicts arise (which they will).

#3 Biggest Innovation Challenge: Resources.

We can never have too many resources, can we? 🙂

Working with resource constraints is a fact of life. But product innovators feel this acutely so.

They’re pushed to accelerate time to market, yet are challenged with selling the business case for the right mix of resources to do just that.

And, of course, this leads to the chicken-or-egg dilemma from challenge #1:

We need a product to test whether customers value it…

But we need customer validation in order to get the resources to build the product!

“My #1 product planning challenge is getting and retaining key resources to minimize time to market consistent and aligned with company priorities.” — survey response

So what’s the solution?

This brings us back to “earlyvangelists”…

Lean practices can and should be adopted and adapted to pursue product innovation inside companies. But product innovators actually need to find two types of earlyvangelists:

  • Earlyvangelist customers.
  • Internal stakeholder advocates, a.k.a. “internalvangelists”.

One of the biggest factors that can derail any new product endeavor is lack of internal support. In product innovation, lack of stakeholder traction can often be a bigger roadblock than customer traction.

These stakeholders not only may have access to essential information and resources but also be able to influence key decision makers whose support is critical to the success of your product initiative.

The larger the organization you work in, the more stakeholders you’re likely to have. It’s important to identify who these folks are and make sure you’re not only bringing them along but in fact converting them into advocates — evangelists — for your product initiative.

Product management didn’t teach me how to get internalvangelists.

The good news is that a lean approach that fuses customer development methods with sound product management practices can be used to get early customers AND build the business case, create alignment, and cultivate internalvangelists iteratively.

Lean product management can get you “earlyvangelists” and “internalvangelists”.

Here’s an example:

Customer learning driven investment strategy

The approach calls for spending plenty of time with customers in a methodical way, systematically testing assumptions at each phase, while also having regular check-ins with folks internally.

Each stage is informed by learnings from the previous stage — “mini business cases”, if you will, at each milestone, instead of wasting time writing a big tome of a business case up front.

Requirements for delivery need only be done when there’s a clear signal to do so. For example, if you find there’s no problem/solution fit, no need to write detailed requirements to build out an MVP or do financial projections. Only on achieving problem/solution fit does it make sense to spend the time doing those activities.

This customer learning driven approach makes for a more market-informed investment approach to the product strategy. This makes it easier to garner, maintain and accelerate stakeholder buy-in, because:

(1) Each investment stage is grounded in real customer data, resulting in less assumptive and more empirically based investment asks.

(2) Smaller continual investments that deliver continuous tangible ROI throughout the process are easier for folks to digest and support than a large bloated one upfront.

(3) Stakeholders continually feel involved in the process, increasing confidence to persevere.

There are surely other variants to this approach. The point here is that lean principles can be fused with sound product management practices to:

  • Test product ideas without a product.
  • Build the business case iteratively.
  • Get alignment and buy-in, and create internalvangelists.
  • And get those magical earlyvangelists!

10 Things To Do To Appear ‘Innovative’

Being “innovative” is all the rage nowadays. Companies big and small, tech and non-tech, are striving to seem innovative to employees and customers.

I’ve worked at such companies, and I’ve helped many product managers working at such companies through my product help calls. As such, I’ve seen companies that are actually trying to be innovative, and those that seem more interested in giving the appearance of being innovative.

So here are ten things a company can do to appear innovative than actually be innovative:

#10. Start using buzzwords, like “MVP”, “lean”, “experimentation”, “hypothesis” and “failing fast” without actually understanding what they mean or what they involve.

#9. Visit Silicon Valley a lot, and come back to share stories of t-shirt wearing founders and how everyone there uses Macs.

#8. Start sponsoring and hosting lots of local tech meetups.

#7. Change the office to look more “startupy”. Or better yet, build a brand new one with an open floor plan, sofas, “nap rooms”, and an Xbox.

#6. Offer lots of free food and unlimited sodas, and host “Pizza Tuesdays” and Wednesday afternoon NERF gun battles.

#5. Tell folks at company town halls that you’re embracing innovation. Just keep saying this. Over and over.

#4. Declare that “mobile is the future”.

#3. Enthusiastically share with employees the millions the company is spending to acquire hot tech startups and entrepreneurs (instead of investing in the existing employee talent).

#2. Declare “entrepreneurship” as a corporate strategy. Or better yet, start challenging employees to be more “entrepreneurial”. Make sure they put it in their professional development plans.

#1. Launch an innovation lab. It may not actually do anything real, but this must be done.

Do these 10 simple things and your company can look innovative too.

Why Products Fail [PODCAST]

Why do products fail?

What are the three important milestones for a new product?

Why is it so important to get to market fast?

How do you manage stakeholders when building a new product?

What is an MVP?

What are the key skills of a good product manager?

How do you stay in touch with current trends?

In 2015, I had the privilege of being interviewed on a podcast series called Yours Productly where we discussed not only these topics, but also:

  • The Product Canvas: why I created it, how to use it, and its growing popularity
  • Lean Startup and Customer Development
  • And what I’ve learned from mentoring over 100 product people around the world.

Frankly, I was amazed at how much ground we were able to cover!

 

You won’t be disappointed!

P.S. In the podcast I talk about a book I was planning to write. I’m not doing that anymore.

Yours Productly is a podcast series hosted by Ravi Kumar, founder of ProductCamp Singapore, where he talks about the business of building great software products with product rockstars and marketeers like Rich Mironov, Steve Johnson, Michael Eckhardt from Chasm Institute, Roman Pichler, and John Mansour, among many others.

Create Your Business Case Using Customer Development

The traditional product innovation process of writing a business case with long-term financial projections, then writing a big PRD, then doing development and launch your product doesn’t work.

At the 2015 Modev MVP and the Lean+Agile DC conferences, I presented an actual example of using Customer Development and Validated Learning to test a new product idea and build its business case, which produced far more impactful results.

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

 

5 steps to validate your product idea without a product

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 a ProductCamp DC event a few years ago, my co-founder and I hosted a session called “Tales From The Product Frontlines”. Our first topic was about this very scenario. It so energized the participants that it took up 30 of the 45 minutes we had been allotted!

During the session, we asked folks 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. 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.

What gives?

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 many product managers are 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 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

The 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 a testable falsifiable hypothesis.
  • Test the hypothesis.
  • Analyze results and learnings.
  • Decide to pivot or persevere.
  • Repeat.

I’ve used these this process to validate ideas for software products, but I imagine it could be adapted for any product concept. (So give it a try and let me know your results!)

1. Write down your customer hypothesis

Most folks typically start with the solution first. That’s the wrong place to start.

You need to take a step back and think very deliberately about your customer. This is true whether you’re pursuing adding a new component to an existing product or are pursuing a brand new product idea.

Note, by customer I mean your buyer — the individual who will buy your product. Even in B2B, you need to think about the specific individual or persona 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 my 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 test your hypothesis. You do this by talking to folks you believe meet your target customer demographic.

Be sure to define minimum success criteria. This 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. You face a pivot when your hypothesis has been invalidated (i.e., proven false).

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 (i.e., validate) 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 test 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 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.

Note that an MVP doesn’t necessarily have to be a software app. It could be a service.

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.

Using customer development to create the business case for your product idea

I talk to so many product folks who are 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, trust me, you’re not alone. Many successful product people have gone through exactly what you’re experiencing — including me!

The problem is we haven’t been taught the right way to pursue this.

We jump headlong into writing a business case, business plan or MRD.

But this doesn’t work.

It’s no wonder then that most folks think writing a business case is a waste of time and hate it.

Furthermore, we were never 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 be the biggest impediment to your product no matter how good your product idea may be.

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

So here’s a new process I’ve been following for a few years now that’s worked much better for me:

Using customer development to create the business case for my product idea

In a nutshell, I deferred asking for major dollars and resources until I absolutely needed to. I used a series of validated learning milestones to build momentum internally and to build the case for investing in my product idea.

Here’s what I did:

1. I quickly sketched out my product strategy on a 1-page Product Canvas. 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

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 six figures — ugh!), 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 was simply my time, so required no money.

To validate our solution hypothesis, 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 or design team, awesome — use them. Your investment “ask” may only be some of their time.)

In this way, I was able to use the resources I had at my disposal for as long as I could 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 build early traction with customers and 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 could leverage 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.

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.

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!

Introducing Product Management into your company – part 2

In part 1, I talked about the challenges of introducing product management into an established organization. Here I share hard-learned lessons on how to avoid common pitfalls and start laying the foundation for long-term success.

Start with why

If you’re looking to bring Product Management into your organization, start with this very fundamental question:

Why?

Seriously, why do you really need product management? What problem are you expecting it to solve?

Improved product development processes?

Better requirements writing? (Ick.)

Maintaining feature lists? (C’mon, seriously?)

Being the demo guy? (Groan…)

Project manage software releases? (Get a project manager.)

Some folks believe dedicated Product Management is needed because there needs to be someone to coordinate all product related activities across the organization — in other words, serve as a glorified air traffic control.

While there is certainly a degree of this involved in product management, you don’t need a dedicated Product Management department just to coordinate your organization’s inefficiencies around your product.

Those inefficiencies could be solved by your various departments better coordinating around product activities. Or they could be re-structured and appropriate processes could be developed around them to ensure continuous delivery.

The ‘why’ question is critical because it sets the expectation for the value Product Management is expected to bring to the organization.

It also crystallizes whether there are ways to solve the problems the organization faces through its current structure.

So why would you want Product Management?

Because you fundamentally understand that sustainable growth comes from innovation…

Tha innovation is about creating monetizable customer value

And product management is the chief vehicle to deliver that.

So if you’re hiring a product manager because you’re developing a software and simply need someone to provide requirements to engineering and project manage the delivery, don’t hire a product manager. Hire a project manager who can double up as a business systems analyst.

Prepare the organization

You must understand that Product Management is a disruptive force, a radical change to the way the organization has been conducting its business thus far. The introduction of a product management function will centralize many functions that were previously diversified. (Fragmented?) Senior leadership MUST think carefully if this is something they want to take the organization through and must prepare to shepherd each of the other departments through their change curves.

In other words, ssenior leadership must take an active role in the success of product management.

Who’s your first hire? And where do they sit?

A more senior individual will bring the experience and know-how to take on a more leadership type role, coalesce the organizations around a coherent product strategy and, when the time comes, leverage their personal network to bring in additional product management talent.

For a growing company, taking over many of the product strategy execution aspects off of the CEO, CIO/CTO, founder, etc. is exactly what the first formal Product Management leader would do. As such, you’ll be better off making your first hire at a more senior level, at least VP or Director. Ensuring sustainable success for the position — and, thus, for the product strategy — in an ideal manner means setting it up in terms of stature and position with respect to the other departments.

A common pushback I hear from organizations that have never hired a product manager is they worry a more senior person may not be willing to be as “hands on” and handle the necessary tactical activities that need to be done.

First, that’s silly, frankly. Just make sure in your hiring process you look for a leader who’s willing to and has demonstrable experience getting their hands dirty.

Second, product management is a unique discipline that necessarily requires one to execute tactically while thinking strategically. It’s the thing that sets it apart from many other disciplines.

Now, as a practical matter, it’s possible the company may simply not have the budget to hire a senior level person since such an individual will naturally command a higher compensation. And waiting to have the right budget may not be an option if the company is in crisis mode where it needs someone to step in to pick up activities that are getting dropped. So the company may be forced to opt for a more ‘junior’ product manager.

Regardless of the experience level of the individual and the title of the role, one of the biggest risks here is where to place this individual in the organization. I would still advocate having this person report directly to the senior most executive in charge of product strategy, including the CEO.

Unfortunately, what often happens is the individual is put under Marketing, Sales or Engineering. (Or, worse, “IT”.) The dangers with this approach are well documented.1

The product manager becomes a support role for the primary function of that department, providing content for marketing materials, doing product demos for sales, or writing requirements and project managing deliverables for engineering. No time to do the critical work of understanding market problems and formulating the product strategy.

Who to hire and where they sit are critical decisions to ensure long term success. I once worked for a company that rotated through five directors and seventeen product managers in just six years. A total of twenty-two. Twenty-two!

Ensure senior sponsorship

Ensure there is someone in a senior executive position who is willing to be the champion for Product Management. This has the greatest impact on Product Management’s long-term success.

You need someone at that level to evangelize the value that product management brings to the organization, and provide the necessary air support when political attacks threaten to disrupt it in its formative stages.

Do you feel lucky? Well… do ya?

So far I’ve talked from the organization’s point of view. What if you’re the first product manager in the company?

Here’s what you should do:

Clarify your role

Because expectations may vary widely, it’s important to clarify your role upfront.

If you’re joining a startup, an enterprise with a visionary CEO, or a company with established lines of business, the CEO or line of business may want to continue to act as the product visionary and retain control over the product direction.

In this case, the Product Manager will likely play a more tactical role, working more closely with engineering on product releases, perhaps supporting marketing and sales activities. Your role with respect to setting the product strategy will be strictly as an influencer.

This may be okay if you’re a newly minted product manager or have got only a few years of PM experience under your belt. Your gaps are in understanding the business, the industry, and the go-to-market strategy. If your company is selling to other businesses, you may have gaps in understanding your customers’ business models.

You can reasonably expect to be coached and mentored with respect to these gaps so that over time you can take over more of the go-to-market and strategic aspects of the job.

And if you are the visionary CEO or line of business GM hiring the product manager, you should prepare yourself to mentor your newly hired product manager over the next several years.

Clarify expectations

You need to have a mutually agreed upon definition of success. Clarify how your performance will be judged. Reconcile these with the scope of the role.

If you’re expected to play a more tactical role, yet deliver product innovation…

Or if you’re measured on the number of defects and customer complaints; yet the role is about market insight and setting the product direction…

Or you’re told they want you to be strategic, but you’ll be measured on tactical things like “on-time” delivery…

These are signs of expectations being incongruous with the role.

Or to put it more bluntly: The role is set up for failure and you should RUN AWAY.

As stated earlier, Product Management is an agent of change, because it changes existing business processes, and takes decision making and responsibilities away from current owners. This creates uncertainty.

To the extent reasonable, talk to everyone. Understand their expectations. Share these findings with your hiring bosses to clarify expectations and the role, and ensure they are congruous. Doing this has the added benefit of helping you establish key relationships and building your credibility. (Important!)

Ensure senior sponsorship

I talked above this above. Regardless of whether you’re coming in with the title of “Product Manager” or “VP or Product”, make sure there is a true believer at the senior executive level who will go to bat for you, give you the space to establish yourself into the role, and support your efforts to be targeted and focused.

Which brings us to:

Focus!

Look, you simply can’t do everything. If you’ve done your homework on the role and expectations fronts, identify what you think are the most pressing problems, share them with your stakeholders, gain their buy-in, and focus relentlessly on the top priorities.

Lower level priorities and new problems will crop up, of course, but at least you’ll be able to fall back on the agreement you reached and have a constructive conversation on re-assessing priorities based on new realities. This gives you a much greater chance to get things done while keeping your credibility intact.

Introducing Product Management into an organization can be fraught with ambiguity, unreasonable expectations, and threats from every corner. But with foresight and planning, it’s possible to set it up for long-term success. Either way, it’s going to be a roller coaster. So saddle up, buckle in, and get ready for a wild ride!

1Further reading:
Marty Cagan: Where Should Product Management Live?
Steve Johnson: Where Does Product Management Belong In An Organization?
Rich Mironov: Where Should PM Report?

Introducing Product Management into your company

If you’re considering introducing product management into your organization, or are the first product management employee hired into a company, then tread carefully! Having done this more times than I care to recall, I can attest there are fewer professional situations more fraught with ambiguity, unreasonable expectations, threats from every corner, and high likelihood of failure for the Product Manager and the organization.

Why would a successful business decide to introduce product management into its organization at all?

In one company I had joined, the business had been extremely successful selling variations of essentially the same product for years and years. But with potential new business drying up, the execs decided the company needed to be more “innovative”, and their answer was to create a Product Management department.

Other reasons could be:

  • With everyone in the company focused on marketing, selling, customer service, managing operations, hiring, and a hundred other things, the organization finds no one is focused on growing the product portfolio.
  • OR… the product portfolio may have grown like wild fire, and now there are multiple versions of the product, causing customer confusion and inefficiencies within the organization. Time to consolidate.
  • The product has become so “feature rich” that sales and marketing no longer know how to position the product to customers, customers cannot be serviced efficiently, and delivery dates keep slipping as each additional piece of functionality adds exponential risk to development and testing.
  • A services company is trying to become a product-focused one, and after lots of wasted time and money realizes they need product management.

For any of these reasons, the company executives decide its time to bring in product management.

Buyer Beware

Although these situations may seem ideal to introduce product management, they abound with pitfalls for the unaware. It’s important for both company execs and Product Management to be mindful of numerous land mines:

Unfounded unreasonably high expectations. Product Management is suddenly looked upon as the silver bullet answer to all the company’s problems.

Not all expectations are created equal. Expectations are also different across each department:

  • Engineering/IT expects Product Management to write requirements, ensure zero scope changes, project manage the delivery, conduct UAT, manage defect resolution, and make seamless release go/no go calls.
  • Sales expects Product Management to be available for every sales call, produce sales collateral, do product demos, commit to product features that will help them close the next big deal with a guarantee to have them all available by the date they already promised to the client.
  • Marketing expects Product Management to provide the content for marketing materials or, worse, wants nothing at all to do with Product Management.
  • Execs expect Product Management to come up with the “next big thing”, have a solid business case behind it, deliver it “on time”, and ensure it makes a ton of money.

What does Product Management do? Most times folks don’t understand the role of Product Management and the value it brings to the organization. Let’s see…

  • Salespeople close deals.
  • Marketing runs campaigns, advertising, promotions, and events.
  • Account Management / Customer Success manages client relationships.
  • Operations manages business processes.
  • Customer Service runs the call center.
  • IT takes care of “all that technical stuff” the rest of the organization would rather not be bothered about.

Pretty straightforward. So what exactly does Product Management do?

And here’s the fun part: even the executives of the company — the same folks who decided to introduce Product Management — may not be clear on what exactly it does or how to measure its value!

Why do we even need Product Management? Infinitely worse is when folks secretly question the decision to bring in product management. This is often more prevalent at the department level than the executive level.

The thinking goes this way: “We’ve been successful all these years without it, so why do we need it now?”

Product Management represents a disruption to tradition and the status quo. And so, it can be seen as a threat. We humans typically don’t embrace change so readily. In one company, IT had historically written the business requirements and Sales always went directly to IT and so was more than happy with this arrangement. When Product Management came into the picture, the battle lines were drawn!

The scapegoat syndrome: A common way for other departments to deal with the perceived threat is simply to blame Product Management for anything and everything wrong with the product.

Suddenly Product Management is getting blamed for deals not getting closed, because the product does not have the features desired by the last “hot” prospect.

If the product has holes, Product Management is called to task for writing poor requirements.

If customers don’t respond to marketing, Product Management is accused of not understanding the customer.

If customers report bugs, Product Management is asked to immediately identify fixes.

Product Management becomes everyone’s favorite punching bag. It’s amazing how fast this happens.

The bottleneck syndrome: Somewhat related to the scapegoat syndrome, except this one is often self-inflicted.

The new Product Manager declares, “Product Management owns the product.” And sure enough, soon he or she does indeed own everything to do with the product.

All decisions, all issues, are swiftly sent to the Product Manager, who quickly gets swamped with putting out one fire after the next.

Pretty soon, no department is getting the support it expects, the backlog piles up, delivery timeframes get jeopardized, the execs are still waiting on the product strategy, and everyone is pointing to Product Management as the bottleneck.

It’s a sucky place to be.

Eyes Wide Open

So before you introduce Product Management into your organization, or sign up as the first product management employee, be mindful of these traps.

Have you ever been one of the first product management employees hired into an organization? Please share your story!

This post was also published on OnProductManagement.net and is part of a two-part series. Read part 2 here.