Category Archives: Startups

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

During the session, we asked product people questions like:

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

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

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

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

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

So what’s the solution?

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

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

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

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

The solution is validated learning

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

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

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

  • Formulate 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, which is 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 truly new product.

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

2. Write down your problem hypothesis.

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

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

3. Validate your customer/problem hypothesis.

Now it’s time to test your hypothesis. You do this by talking to folks you believe meet your target customer demographic.

Be sure to define a minimum success criteria, which is the minimum amount of data you will need from the test to justify investing more time, effort or resources into proceeding with the idea.

When you’ve met your minimum success criteria, analyze your data, and decide whether to pivot or persevere.

A pivot is a fundamental change in direction of your business model or product strategy. 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 ideally pay for) an early version of the product. You’re also looking for directional feedback to identify the “right” handful of features to build for these early customers to prioritize your product development.

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

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

5. Validate your solution via an MVP.

There are many misconceptions about what constitutes an MVP, and I’ve written about these before. In short, an MVP is an actual product that attempts to deliver real value to customers.

It’s “minimum” in the sense that it’s an attempt to deliver the absolute necessary set of features or capabilities needed to solve the customer’s problem for which the customer will pay.

A primary outcome of the previous step is being able to understand your customers’ problems at a granular level, which helps prioritize the initial set of features to build. This drives the definition of your MVP.

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

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

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.

How To Define An MVP: A Case Study

In my last post, I talked about how a minimum viable product (MVP) is not the smallest collection of features to be delivered. An MVP is basically an in-market experiment of a product idea that involves delivering real product to actual customers to get their feedback.

An MVP can be tested whether your idea is a brand new product or a new feature for an existing product.

And even if your product is software, your MVP doesn’t necessarily have to be software too.

Folks may be familiar with how Groupon started as a WordPress blog, called “The Daily Groupon”, on which the team posted daily discounts, restaurant gift certificates, concert vouchers, movie tickets, and other deals in Chicago area.

Food On The Table, a family meal planning and grocery shopping site eventually acquired by the Food Network, started by working with their customers individually, creating meal plans and shopping lists for them on spreadsheets and email, and then bought and delivered food items themselves.

So how do you go about defining an MVP for your product idea?

It starts with having a hypothesis for what features or capabilities you believe need to be delivered to your target customer in order to provide them value.

This is predicated on having done the hard upfront work of validating your customer’s problem (that it exists, it’s urgent, and pervasive), and then maybe even having tested a prototype of your solution vision.

If you feel you have a good enough understanding of your customer’s problem (pain point, job to be done, etc.), use that as a basis to identify what you believe are the must-have features for your MVP that are aligned with your solution vision.

Then test that MVP with real customers. Evaluate your results. Rinse and repeat.

To make this more tangible, here’s an example from my own experience.

For a product idea we had, we wanted to test 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 believed to be the top problems that our solution absolutely had to solve for first.

We 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. We formulated a testable falsifiable hypothesis around the ability of each screen to solve a specific problem.

We then set up a number of customer interviews to test our problem hypotheses. During these customer conversations, we listened 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 point and were directionally correct in our solution approach.

As a primary outcome of this work we were able to understand our customers’ problem at a granular level, which helped prioritize the initial set of features to build. That drove the definition of the minimum viable product version of our solution.

And that’s what we did. We built just those features, and nothing else, and delivered it to those handful of early customers.

In fact, our first MVP wasn’t software. Our first MVP was more a concierge type service, sort of like what Food On The Table did — we “manually” delivered the service to each customer individually.

We learned a ton of really useful stuff. Things like what was really important to the customer, what features of the service they used more often than others, real insights into their workflow and how our solution could help improve it, and — crucially — what they were willing to pay for.

We used these learnings to then define a software MVP, and deliver it to early committed customers. The learnings from our “concierge” MVP experiment helped boost our confidence in defining the requirements for our software MVP. In other words, it was much less of a guess than it otherwise would have been.

We didn’t really bother with calling the software MVP a “release 1.0” or “version 1.0”, because that was irrelevant. We just focused on testing the solution until we received customer validation that it was truly providing value.

That gave us the confidence to know our product idea was “good to go” to scale up, put some real sales and marketing muscle behind it, and sell to more customers.

There’s no one way necessarily to approach an MVP. This is just one example of an approach. As Eric Ries states, defining an MVP is not formulaic: “It requires judgment to figure out, for any given context, what MVP makes sense.” Hopefully, this example gives you a template to define and test your own minimum viable product for your next great product idea.

I’ve created a handy primer on what is a minimum viable product. Download it below. I hope it helps you to become a pro at defining an MVP for your next great product idea!

 

An MVP Is Not The Smallest Collection Of Features You Can Deliver

Source: Spotify

Source: Spotify

There’s a lot of discussion and confusion about what is and isn’t a minimum viable product (MVP).

Worse, many execs have latched on to the term without really understanding what truly constitutes an MVP — many 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, lots of folks in the enterprise world, including in product management, over-think 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 deliver to customers. Wrong. It’s not.

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 new product or feature, we don’t.

Now, the challenge with the concept of a minimum viable product is it constitutes an entirely different way of thinking about our approach to product development.

It’s not about product delivery actually — in other words, it’s not about delivering product for the sake of delivering it or to hit a deadline.

An MVP is 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 definition.


Download The Handy Primer “What Is An MVP?” >>


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 an MVP 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. So a minimum viable product is an attempt — an experiment — to deliver real value to customer.

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. An MVP must attempt to deliver value.

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. A few years ago, I had to build an online form builder app that would allow customers to create online payment forms without the need to write any HTML or worry about connecting to a payment gateway. Before having our developers write a single line of code to build the product, we first offered customers the capability as a service: we would get their specs, and then manually build and deliver each online payment form one-by-one, customer-by-customer. Customers would pay us for this service.

This “concierge” type service was our MVP version of our product vision. Of course, it wasn’t scalable. But we learned a heck of a lot: most common types of payment forms they wanted, what was most important to them in a form, frequency of wanting to make changes, reporting needs, and how they perceived the value of the service.

We parlayed these learnings into developing the software app itself — which, by the way, we delivered as an MVP to early customers to whom we had pre-sold the software product. (Yes, we delivered two different types of MVPs!)

Whether you take a “concierge” approach or your MVP is actual code, it most definitely does NOT mean it’s a half-baked or buggy product. (Remember viable from above?)

It DOES mean critically thinking through the absolute necessary features your product will need day 1 to solve your early customers’ top problems, focusing on delivering those first, and putting everything else on the backlog for the time being. 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 your riskiest assumptions, formulating testable falsifiable hypotheses around these, and using an MVP — a minimum viable product version of your product vision — to prove or disprove your 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 while they may deliver value to you and your product idea, they’re not delivering actual value to the customer.

At the same time, the traditional product management exercise of identifying all the features of a 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 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.

I’ve created a handy primer on what is a minimum viable product. Download it below. I hope it helps you to become a pro at defining an MVP for your next great product idea!


Download The Handy Primer “What Is An MVP?” >>


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 this simple, but fundamental question:

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? Maintaining 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 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.

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, 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, 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 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, product management is a unique discipline that necessarily requires one to execute tactically while thinking strategically. Second, just make sure you hire the right person who can execute as tactically as you need.

Now, it’s possible the company may simply not have the budget to hire a senior level product management professional, since such a person 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.

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 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? 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

This is part 1 of 2. Also published on OnProductManagement.net. Part 2 is 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 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 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 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 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!

Why do we even need Product Management? Infinitely worse is when folks secretly question the decision to bring in Product Management. This is sometimes prevalent at the department 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. As such, it is seen as a threat. We humans 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 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.

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.

 

4 Key Tips For Attracting A Non-Technical Co-Founder

Recently Michael Hughes of CoFoundersLab wrote a nice piece on how a non-technical founder can attract a technical co-founder. I’ve read many similarly written blogs and presentations. Most all say the same type of thing: build a prototype, learn to write code, talk to customers. So I thought it would be interesting to look at the opposite situation: how can a technical founder attract a non-technical co-founder?

It strikes me that you could take many of Michael’s points and apply them equally to attracting a non-technical co-founder. Especially the ones about focusing on attracting a co-founder as opposed to finding one, getting into the right mind set, and a co-founder wanting to work with you instead of for you.

In fact, you could take many of his sentences and simply turn them back around to a technical founder. For example: “Repeat this to yourself until you believe it in your bones”: your idea isn’t the best idea, and a non-technical co-founder doesn’t want to work for you on simply selling your idea.

I’ve come across too many technical founders who see the problem as simply a question of sales. In their minds, they of course have the most brilliant product idea, and they may even have spent weeks or months building a product with slick features. Now, all they need is a “sales guy”, “marketing guy” or “business guy”, and of course the money will come rolling in.

If the product doesn’t sell, it’s easy for the technical founder to simply blame the sales guy or marketing guy. After all, clearly the product is great, so if it’s not selling it’s obviously sales or marketing’s fault!

Michael rightly says: “You may very well have the next game changing idea, but that’s missing the point.” The missing point in this case for the technical founder is market validation.

With all of the education out there about customer development, talking to customers, “get out of the building”, etc., I still meet many technical founders who are so completely convinced of their product idea, and they’ve spent months and even lots of money to build a product, yet have no proof whatsoever that a single customer would actually be interested in, let alone buy, their product. That’s because they’ve spent zero time in the marketplace actually trying to identify who their target customer may be and whether these customers actually care. Often times their market research has been limited to a few conversations with trusted friends and family, or they rely on broad industry research or market trends. But unless friends and family are your target customers, their opinions, while interesting and ego-flattering, are utterly irrelevant.

Technical founders are sometimes surprised when non-technical co-founders start providing input into the product features. Reality check: if they’re out there talking to prospective customers, they’re absolutely going to come back with input on features and capabilities that they feel need to be developed to satisfy your customers.

So how do you attract a potential co-founder? You can start with these four tips:

1. Make sure you’ve identified a real problem.

An idea is worthless unless you can clearly articulate who is your potential customer and what problem it solves for them. And you need to be able to state the problem from the customer’s point of view.

If a technical co-founder looks to a prototype or code as a form of commitment from a non-technical founder, a non-technical co-founder is looking for work done to obtain actual market validation as a form of commitment from a technical founder. Currency here is in the form of actual customer interviews.

2. Learn to do customer development.

If you want to gain respect from a non-technical co-founder, learn to how to find and interview customers, identify early adopters, understand your market, and get buyers. This will show that you haven’t formed your idea or developed your product simply in your head, but you’ve done so in response to the demands of your market. Nothing is more impressive than being able to clearly articulate who is your early adopter customer, and better yet, show that you have a paying early adopter customer.

3. Start talking about your product in terms of benefits, not features.

When describing their product ideas, many technical founders describe a laundry list of features. While some of your features may actually be pretty cool, the reality is no one actually cares. What customers really care about is how your product solves their problems, and that means being able to communicate in benefits, not features.

If you’ve done #1 and #2, #3 becomes easier to do. If you’re able to speak in terms of benefits, you will demonstrate to a non-technical co-founder a grounded, realistic understanding of your market.

4. Stop saying “There is nothing like this out there” or (worse) “There is no competition.”

Sorry to burst your bubble, but odds are very high your idea is not that unique. Repeat this to yourself: There is always competition for my product.

Keep in mind the competition may not always be another company or product. Your competition may very well be how customers are solving their problem today. A great example is Quicken. One of the biggest competitors Quicken was competing with when it first launched was the paper checkbook and pen. Your biggest competition is often current customer behavior.

Just like Michael says in his article, remember to treat your non-technical partner like a true partner, not just the person who will “get sales”. The key to attracting world talent here is to show commitment to obtaining real, tangible progress in your target market. Best of luck!

What Lean Startup Machine Can Teach Product Managers

Update and disclaimer: I had originally attended Lean Startup Machine in October 2012, was a mentor in September 2013, and will be mentoring again this year.

If you’re a product manager or marketer, you need to attend Lean Startup Machine. Why? So you can learn to be wrong. A lot. And faster.

Lean Startup Machine is an intensive educational workshop that lasts 49 hours (yes, you read that right) where attendees learn how to use Lean Startup principles, particularly Customer Development techniques, to validate an idea for a new product or service with actual customers. So if you have an idea that’s been rolling around your head for some time, come to LSM and in 49 hours you will leave either with the real knowledge that your idea stinks (because there are no customers) or quite possibly with a commitment from an early adopter customer in the form of a purchase order, contract or credit card number, or non-cash currency in the form of time, a registration, and email submission or letter of intent. (No, I’m not making this up.)

If you’re unfamiliar with Lean Startup or Customer Development, read this, this, and this.

This past weekend I attended the Lean Startup Machine (LSM) workshop held at The Fort.vc in downtown Washington DC. It started Friday at 6pm and ended on Sunday at 7pm. About 50 people participated representing a spectrum of backgrounds and industries. The youngest attendee was still in high school while some of us, like yours truly, could be considered more “seasoned” professionals.

The basic format is this: anyone with an idea has 50 seconds to pitch it, everyone votes, and the ones with the most votes become team leaders. Everyone else then joins a team. The teams then spend the rest of the weekend validating the assumptions behind their ideas with real customers and iterating based on their feedback with the goal of getting to a point where you can claim customer validation for your product idea. Assumptions and iterations (also called pivots) are tracked via the Validation Board. Proof of validation is in the cash or non-cash currencies mentioned earlier. If you think this sounds unrealistic to accomplish over a weekend, read this.

The first thing the team does is identify who they believe is their target customer for their product idea – called the Customer Hypothesis – and what problem they believe their solution solves for these customers – called the Problem Hypothesis. The team then identifies all the assumptions underlying their Problem Hypothesis and then picks the Riskiest Assumption among all these. This is the most important assumption of all your underlying assumptions – the one that if it turns out to be false tells you the problem you thought exists actually doesn’t.

With the Riskiest Assumption identified, the team creates an experiment to invalidate that assumption. What this means is you go find real customers to talk to who can tell you you’re wrong. That’s right: the purpose is not to be proven right; it’s to be proven wrong.

What this also means is that you’re getting out onto the street and interviewing actual strangers to find out (a) if they meet your Customer Hypothesis, and (b) if they do, do they have the problem you think they do?

If you get enough potential customers confirming your assumption, you may be on to something and may have the opportunity to actually pitch them your idea in the form of a minimum viable product. It’s more than likely, though, either you won’t find any suitable customers or they’ll tell you they don’t have the problem you thought they did. And that’s when the real fun begins, because you’re then forced to pivot, which means either re-visit your Problem Hypothesis or perhaps test your hypothesis with another type of customer.

This happens over and over at an extremely rapid pace. You are in a constant flow of documenting your hypothesis, creating your experiment, listing your questions for the customer interviews, getting out of the building to go find people to talk to, capturing your findings, and then repeating the cycle. You use the Validation Board, sticky notes and markers to keep track of all this stuff. Along the way, you’re guided by extremely helpful mentors – former and current Lean Startup entrepreneurs and practitioners. There are also presentations by other lean practitioners to share their experiences and insights, and to keep you motivated.

The workshop ends with team presentations on Sunday evening and a winner is announced.

LSM was a unique and unforgettable experience that I’d recommend to anyone with a product or business idea. But I was particularly struck by how much product managers and marketers can benefit from participating in LSM and learning the Lean Startup approach. Why?

1. To get better at customer research. Product managers and marketers need to be spending their time understanding customer problems. While data and metrics can tell you a lot, nothing will tell you more than actual customer interviews. But there’s a right and wrong way to do this. LSM will give you a crash course in the right way so you can get to the true nature of the customer’s problem as quickly as possible.

2. To learn how to validate your ideas quickly. Product managers are natural problem solvers. But running with the first idea that strikes as a solution will cause you to run into problems of your own. So testing ideas is important. “Build and launch” is not the way. “Test and learn” is. LSM will force you to think critically about the most important components of your idea – who is the customer and what problem do you think you’re solving for them – and give you the tools to rigorously and systematically test these. The structure of the workshop will force you to go through this hypothesize-test-learn loop as quickly as possible so you can start discarding bad ideas quickly so as to get to the potentially good ones faster.

3. To get their teams past debating opinions and intuition, and focused on validated learning. Product managers typically work in teams whose members don’t report to them. So the ability to influence defines success or failure for a product manager. Everyone thinks their idea is the most credible and, particularly in agile teams, everyone has an equal voice. Even when data is available, it is still subject to interpretation. LSM gives product managers the tools that enable them to get past the opinions and subjectivity by capturing everyone’s point of view as a hypothesis that can be rigorously and systematically tested with actual customers. Product teams can cycle through the opinions and get to what customers really want faster while maintaining team harmony.

4. To practice your influencing skills. Related to the above. A product manager with poor influencing skills will fail. Period. LSM is a team-based workshop. You’re working with total strangers to validate an actual product idea. And you’ve got precious little time to do it. Everyone’s opinion counts. The cauldron of LSM is perfect to test and refine your ability to influence.

5. To learn the value of doing and being decisive. LSM will teach you to quickly get over your fear of having the perfect answer, being wrong or looking stupid, which often becomes a roadblock to actually doing anything. Instead, you’ll be forced to be decisive and do stuff so you can learn from mistakes quickly.

6. To learn that you’re often wrong. Some product managers fall into the trap of thinking they’re always right by nature of being a product manager. “Product management represents the customer, so of course I know best!” is how the thinking goes. This is dangerous. A product manager’s value is not in being the know-all about what’s best for his or her customers. Rather, it’s in the product manager’s ability to truly understand the customer’s problems and lead the organization to visualize and deliver a viable and innovative solution that the product manager’s value lies. LSM will teach you how to do this in a sustainably repeatable process.

7. To learn to distinguish between vision and details. Every product starts with a vision of a potential solution to a problem. Being natural problem solvers, product managers often have a vision for how to solve their customers’ problems. It’s a fine line between knowing when to keep to the vision and when to admit it just won’t work. LSM is a great way to learn how to stay true to a vision, but be flexible on details.

Check out when and where is the next Lean Startup Machine workshop here.

Have you attended LSM? What was your experience like? What were the key lessons you took away?