Bootstrapping A Startup Product In Your Company

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!

A Case Study In Defining An MVP

In my last post, I talked about how an MVP is not the smallest collection of features to be delivered in the first version of your product. An MVP is about delivering real value to customers for the purposes of maximizing validated learning.

So how to go about defining an MVP? It all depends on what are the riskiest assumptions in your product strategy and the stage of your startup product. In other words, how far along you are on the path from problem/solution fit (do you have a problem worth solving) to product/market fit (have you built something people want). There’s not necessarily a “one-size-fits-all” formula for defining an MVP. However, here’s an example from my experience that I thought I’d share as a case study.

For a product idea we had, we wanted to validate our understanding of our customers’ top problems and get directional feedback on our solution approach. Directional feedback meant identifying the “right” handful of features to build first for early customers.

Based on some early customer conversations and market research, we developed a view of the problem domain. We sketched out our product vision on the Product CanvasTM, which allowed us to break down the problem domain into discrete problems and formulate testable falsifiable hypotheses around what we understood to be the top problems that our solution absolutely had to solve for first.

We also built a clickable mockup defined by the key elements of our solution captured in our Product Canvas exercise. To keep things simple, we built a screen for each discrete problem to represent our solution vision — real html and css, in color, no lorem ipsum, with clickable interactions to represent the primary workflow through the screens. (We didn’t build out every interaction — just the main ones.) Finally, we formulated a testable falsifiable hypothesis around the ability of each screen to solve each problem.

We then set up a number of customer interviews and systematically validated first our problem hypotheses and then our solution hypotheses. During these customer conversations, we listen carefully to fully understand our customers’ world views and their current work flows, even noting the emotions in their voice and their body language (during in-person meetings, when we could do them) as they discussed their challenges and reacted to our screens. We were deliberate and meticulous about documenting the results.

It turned out that while we had identified a viable problem domain, our view of what early customers considered as their chief problems was invalidated. We also learned that while our solution approach was generally in the right direction, there were features that we had not envisioned that early customers considered as must-have’s in the initial delivery. As a massive bonus, we were actually able to garner a handful of very early customers who were willing to co-test the solution with us, further validating the fact that we had pricked a real pain and were directionally correct in our solution approach.

At this point, you may be asking, so was the clickable mockup our MVP? No. It did offer validated learning, but remember we didn’t actually deliver anything to early customers. But a primary outcome of the above work was that we were able to understand our customers’ problem at a granular level, which helped prioritize the initial set of features to build. That drove our MVP definition.

And that’s what we did. We built just those features, and nothing else, and delivered it to those handful of super early customers. When we did, once again, we formulated a set of testable hypotheses to ensure we were continuing to drive our product development based on validated learning. We didn’t really bother with calling it “release 1.0″ or “version 1.0″, or considered the product as “launched”, because that was irrelevant.

I’m not saying this is the way to approach an MVP in every case. It’s just an example of an approach we took. As Eric’s states, defining an MVP is not formulaic: “It requires judgment to figure out, for any given context, what MVP makes sense.”

MVP Is Not The Smallest Collection Of Features You Can Deliver

As product people in the non-startup world familiarize themselves with Lean Startup concepts, there’s a lot of discussion and confusion about what is and isn’t an MVP. Worse, many execs and CEOs have latched on to the term without really understanding what truly constitutes an MVP — in effect, they use it as a buzzword, and as a synonym to mean a completed version 1.0 ready to be sold to all customers.

Buzzwords are meaningless. They represent lazy thinking. And using “MVP” to mean “first market launch” or “first customer ship” means you’re back to the old waterfall, traditional project-driven software development, sales-focused approach. If that’s your approach, fine. Just don’t call what you’re delivering an MVP.

On the flip side, I find lots of folks in the enterprise world, including product management, over-thinking the term. It gets lost in the clever nuances of market maturity, and a long entrenchment in the world of release dates and feature-based requirements thinking. Many folks think of MVP as simply the smallest collection of features to satisfy customers. The problem with that approach is it assumes we know ahead of time exactly what will satisfy customers. Even if we’ve served them for years, odds are when it comes to a startup product, we don’t.

The challenge is MVP constitutes an entirely different way of thinking about our approach to new product development. It’s not about product delivery actually. It’s about validated learning. As such, it puts customers’ problems squarely at the center, not our solution.

Reality check: Customers don’t care about your solution. They care about their problems. Your solution, while interesting, is irrelevant.

So if we’re going to use the term “MVP”, it’s important to understand what it really means. Fortunately, all it takes to do that is to go back to the source.

Minimum Viable Product (MVP) is a term coined by Eric Ries as part of his Lean Startup methodology, which lays out a framework for pursuing a startup in particular, and product innovation more generally. This means we need to understand the methodology of Lean Startup to have the right context for using terms like “MVP”. (Just like we shouldn’t use “product backlog” from Agile as a synonym for “dumping ground for all possible feature ideas”.)

Eric lays out a definition for what is an MVP:

“The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

Eric goes on to explain exactly what he means (emphasis mine):

MVP, despite the name, is not about creating minimal products… In fact, MVP is quite annoying, because it imposes extra overhead. We have to manage to learn something from our first product iteration. In a lot of cases, this requires a lot of energy invested in talking to customers or metrics and analytics.

Second, the definition’s use of the words maximum and minimum means it is decidedly not formulaic. It requires judgment to figure out, for any given context, what MVP makes sense.

Let’s break this down.

1. An MVP is a product. This means it must be something delivered to customers that they can use. There’s a lot that’s been written about creating landing pages, mockups, prototypes, doing smoke tests, etc., and considering them as forms of MVPs. While these are undoubtedly worthwhile, and certainly “lean”, efforts to gain valuable learnings, they are not products. Read Ramli John‘s excellent post on “A Landing Page Is NOT A Minimum Viable Product“. A product must attempt to deliver real value to customers.

Which leads us to…

2. An MVP is viable. This means it must try to tangibly solve real world and urgent problems faced by your target customers. So it’s not about figuring out the smallest collection of features. It’s about making sure we’ve understood our customers’ top problems, and figuring out how to deliver a solution to those problems in a way that early customers are willing to “pay” for. (“Pay” in quotes as it depends on your business model.) If we can’t viably solve early customers’ primary problems, everything else is moot. That is why an MVP is about validated learning.

3. An MVP is the minimum version of your product vision. Ramli John provides some fascinating examples of MVPs using email, blogging, video, and plain old hustle. Even if our MVP is actual code, it most definitely does NOT mean it is a half-baked or buggy product. (Back to viable, above.) It does mean thinking through critically the absolute necessary features our product will need day 1 to solve our early customers’ top problems, building only those at first, and putting everything else on the backlog until we’ve achieved product/market fit. It also means being very deliberate about finding those “earlyvangelists” that Steve Blank always talks about.

Ultimately, the key here is “maximum amount of validated learning”. This means being systematic about identifying our riskiest assumptions, formulating testable falsifiable hypotheses around these, and using our MVP to prove or disprove our hypotheses. Now, validated learning can certainly be accomplished via a landing page, mockup, wireframes, etc. And it may make sense to do these things. Super. But don’t call them MVPs, because they’re not delivering actual value to the customer.

At the same time, the traditional product management exercise of identifying all the features of our product, force ranking them, and then drawing a line through the list to identify the smallest collection to be delivered by a given timeframe is also not an MVP. Why? Because this approach is not predicated on maximizing validated learning. If you’re going to pursue this approach, go ahead and call it Release 1.0, Version 1.0, “Beta”, whatever. But don’t call it an MVP.

An MVP is about not just the solution we’re delivering, but also the approach. The key is maximizing validated learning.

Stand Your Ground

Product people: Stand your ground.

If you’re being pushed by engineering to begin development, threatening you’ll otherwise lose your development resources, but you think there’s still crucial product strategy, product definition or customer development work to be completed, stand your ground.

If you’re being cornered into an arbitrary market launch date that adds an unreasonable level of risk to the product delivery and value proposition, stand your ground.

If you’re being coerced into a software development process, because it’s the latest thing or there are zealots blindly evangelizing its benefits with no real perspective on your customers or business, stand your ground.

If the scrum team is complaining to the CIO or any executive who will listen that you’re not physically present with the scrum team 24/7, and you feel your time is better spent in the marketplace with customers, stand your ground.

If Marketing is pushing for a full court press market launch well before any market assumptions have been validated, and you feel a soft launch is better to de-risk the product strategy, stand your ground.

If Business Development is pushing you to add that one feature that will enable them to close that gajillion dollar deal, and that feature makes no sense for any of your other target customers, stand your ground.

If Sales is pushing you to deliver the product earlier because they arbitrarily made up a delivery date to sell a prospect, stand your ground.

If your CFO is badgering you for budget and ROI estimates well before your product strategy has been validated or you’ve achieved even problem/solution fit, give him or her your estimates, say they’re a 100% guess, are practically guaranteed not to hold up, and you won’t be using them to manage the project. Stand your ground.

If your CEO is forcing you to define your MVP based on his or her own personal vision of the product with no customer validation to inform the product strategy, definition and delivery approach, yes, stand your ground.

This is not to say you should be unreasonable, stubborn or inflexible. Be professional. Be collaborative. Listen to them. Understand their perspective. Address concerns. But if you feel you have a case, if you’ve done your homework and feel confident in your point of view, stand your ground.

And don’t be stupid. Be sure to have your facts. Have a rational, justifiable case. If you have those, and can back up your assumptions, stand your ground.

State your case clearly, coherently, calmly, rationally, respectfully, professionally. Even passionately. Stand your ground.

You may be challenged. Expect it. Stand your ground. You may be overruled. Possibly. So what? You’ll have stated your case. Stand your ground. You may be ridiculed, shouted, screamed or hollered at. Stand your ground. (And ask yourself if you really want to work in such a toxic environment.) They may be upset with you, but they’ll sure as heck will respect you, because you stood your ground.

You are the product owner. Know your product, its value proposition, its business model, your roadmap, and your delivery process. Above all, know your customers. Do that, and you’ve earned the right. So stand your ground.

Because when you stand your ground, you’re standing up for your customers. And, as the product person, that’s your job.

Introducing Product Management Into Your Company – Part 2

In my previous post, 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 on product management into your organization, start with the most fundamental of all questions:

Why?

Seriously, why do you really need product management? What problem are you expecting it to solve? Innovation? Improved product development processes? Better requirements writing? Writing feature lists? Being the demo guy?

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. Perhaps the existing departments could take on various Product Management functions, or could be re-structured, and appropriate processes can be developed around them to ensure continuous innovation. If this is not possible, and centralized product focus is needed, then perhaps introducing Product Management does makes sense.

Tip: 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 delivery, don’t hire a product manager. Hire a project manager who can double up as a business systems analyst.

Prepare the organization

The fact is 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 centralized product management function will do just that: centralize many functions that were previously diversified. 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.

Who is 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, quickly formulate the product strategy and develop a roadmap, be better able to articulate the value of product management, 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, COO, etc. is exactly what the first formal Product Management leader would do. As such, I’m of the opinion it’s best to make your first hire at a more senior level, at least VP or Director. This is not about title chasing. 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 push back 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 of all, product management is a unique discipline that necessarily requires one to execute tactically while thinking strategically. Second, frankly, just make sure you hire the right person who can execute as tactically as you need.

Now, understandably, the company may simply not have the budget to hire a seasoned product management professional, since such a person will command a higher salary. And waiting to have the right budget may not be an option if the company is in a 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.

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 into marketing, sales or engineering. The dangers with this approach are well documented.1 In effect, 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 sponsor and champion for Product Management. I’m talking someone at the SVP+ level. In my experience, 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? The Product Management Journal has some great tips on introducing Product Management into a startup. I expound on those to encompass any organization:

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, Product Management may 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 is strictly as an influencer. You must ask yourself, are you cool with that? If not, the role is simply not a fit. Move on.

Clarify expectations

You need to have a mutually agreed upon definition of success, and clarify how your performance will be judged, and 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, these are signs of expectations being incongruous with the role. (In other words, bluntly, the role is set up for failure. My advice: 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 build your credibility. (Important!)

Ensure senior sponsorship

Same as discussed above, except now from the individual’s lens. Regardless of whether you are coming in with the title of VP or Product Manager, be 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 of course crop up, but at least you’ll either be able to fall back on the agreement you reached or 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 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

I had written a two-part post on this topic as a guest blogger on OnProductManagement a year and a half ago. Recently, I’ve had some conversations with folks on this very topic, so felt the lessons shared are worth repeating. So here is part 1. Part 2 is here.

If you are considering introducing Product Management into your organization, or are the first Product Management employee hired into an established business, then tread carefully! Having done this three times, 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 of the companies 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.
  • On the other hand, 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 itself 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.

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, project manage the delivery, conduct UAT, manage defect resolution, and make 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, and have them 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 does market research, advertising and promotions.
  • Operations manages call centers and business processes.
  • Account management manages client relationships.
  • 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!

Why do we even need Product Management? Infinitely worse is when folks secretly question the decision to bring in Product Management. This is typically prevalent at the department head and rank & file levels.

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. As such, it is seen as a threat. We human beings typically don’t embrace change so readily. In one company, IT had historically written the business requirements and the business was more than happy with this arrangement. When Product Management came into the picture, the battle lines were drawn!

The scapegoat syndrome: A popular way for other departments to deal with the 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 in the product, 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.

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. In my next post, I’ll share hard fought lessons on how you can avoid them and prepare for long-term success.

Have you ever been one of the first product management employees hired into an organization? Please share your story. I’d love to hear from you!

Read part 2.