Category Archives: New Product Development

When I built products the stupid way

In 2007, ProductRepair (name changed), a market leader in its industry, was facing some serious threats:

A rapidly maturing business.

New “digitally native” entrants with greatly enhanced data collection abilities.

A 100% call center based customer service model, with an escalating cost per interaction.

Service partners with increasingly divergent strategies.

Legacy IT infrastructure that made it difficult to compete.

To tackle this, the company’s product management team proposed an innovative and bold “interactive customer web portal” (remember: this was 2007), thus transforming the company’s traditional “brick & mortar” type business model into a “21st century digital model”.

The vision was pretty cool actually. The strategy was to provide:

  • “An integrated closed-loop customer experience.”
  • “Comprehensive product setup and support.”
  • “Enhanced full-service customer support.”
  • “Interactive multi-channel communication.”
  • “Cross-sell and up-sell platform.”

(Yes, those were the actual words used in the presentation to the CXOs.)

The benefits were the usual stuff: increased value-add, improved customer satisfaction and retention, call reduction, after-sale revenue opportunities, “big data” insights, etc.

The new digital business was to have five core capabilities:

  1. A product “locker” for the the user to keep track of their purchases
  2. Self-troubleshooting
  3. Live chat and email support (again: 2007, so pretty new stuff back then)
  4. Request service on their malfunctioning product, with real-time claim adjudication, and service status and resolution
  5. Up-sell/cross-sell platform

As an ambitious young product manager, I was put in charge of building and launching this bold new digital capability.

Our (my) approach was classic:

A month spent writing a PRD and an RFP to source a development partner.

$10,000 spent on “consumer research”.

$320k in 6 months spent to get to “First Release”.

Another $10,000 spent to produce a flashy “demo” that we could showcase at the Consumer Electronics Show.

Over $1 million spent in a year to add features, fix bugs, and re-design the system.


E.P.I.C. Fail.

Delivery was late. Customers hated it. Sales was unhappy. Execs were angry.

It wasn’t just that we took a waterfall development approach vs. agile…

It’s that we made a terrible business decision: we decided to deliver our entire product vision in our first release.

This “build it all” approach added a tremendous amount of needless risk to our delivery and strategy.

If you’re reading this shaking your head, laughing at me, I know, I know…

In the new world of agile/lean, we’re all much savvier to the benefits of an incremental and iterative approach to product development.

Credit: Jeff Patton

Needless to say, I learned my lesson (the hard way, I might add)…

And yet, turns out, product managers still struggle with this.

See, it’s not a choice between waterfall vs. agile. It’s not a project management problem.

It’s not even a software development methodology problem.

It’s a business innovation problem.

That’s why when I recently saw this question posted by Ganesh on a PM community, my past flashed before my eyes, and I knew I had to help him out.

Here’s his question:

I need some advice around building a service incrementally around user needs.

We’re building an online service that has the following needs (in priority): Cereal, Beef, Vegetable, Fruit. (Shardul’s note: Names of actual needs not listed here to protect any confidentiality concerns.)

As Cereal is the number 1 need, my idea was to design and build this need out and test it with users while further researching what users wanted around Beef. Once we have more information around Beef, we can then incorporate that into the Cereal prototype, thus building it out like building blocks. And repeating this cycle till all needs are met and the service is built out incrementally.

The opposite is that we research ALL the needs in one sprint, and find out what people want. Then build the whole page, which has all the needs together. I can see how this would be positive in terms of seeing the entire picture, and keeping the content in context of each other. But my concern here is that we miss out the details.

Any advice would be appreciated.

Maybe you’ve been faced with a similar dilemma…?

Here’s the answer I gave to Ganesh, verbatim (though, with the food groups):

In case you can’t read the text in the image…

Ganesh, since I don’t know the complexity of your service (I don’t want to assume just because you’ve listed four functions that “seem” straightforward that there isn’t complexity), allow me to share an approach we took on a previous job I did as a thought provoker.

My inclination is always to get product to customers as fast as possible without compromising on quality and ensuring every release attempts to deliver real user (and business) value.

With that philosophy in mind…

I’d consider asking a Designer to sketch out the “whole picture”, like a clickable mockup or prototype (no “plumbing” behind it) and see if I can get some qualitative user feedback on it. I’d take this option if I believed that this could be accomplished relatively quickly.

Once done, I’d actually consider going ahead and building and delivering the Cereal functionality first because you stated it’s the #1 need, and I can get users to actually use the thing and start getting real feedback on it allowing me to focus on usability improvements (because they will be needed.)

I can then prioritize these needs along with the remaining functions on my roadmap/backlog for delivery. For example, my next release could strictly be usability improvements for Cereal, or these + an increment of the Beef need (assuming there’s value in delivering it in increments), or Cereal usability improvements + Beef in its entirety. (I’m assuming here Beef is second most important after Cereal.)

By having my designer sketch the “whole picture” upfront and sought user feedback on it, I’ve hopefully reduced the risk of wholesale design changes downstream. (Though, it’s still possible.) Even if there are changes that need to be made to the Cereal feature as you get user feedback and look to add the other features, a competent designer should be able to manage the process (since they’ve already done the “whole picture”) in concert with you, and determine the best approach to releasing them to the user.

This allows me to accomplish all three of my needs: design for the whole picture, get product to users as quickly as possible, and start acting on user feedback.

I would opt not to have the designer sketch the “whole picture” if it was going to take a long time (like a month).

The crux of my answer is a strong proclivity for getting product to customers as fast as possible without compromising on quality, and ensuring every release attempts to deliver real user (and business) value.

It’s a philosophy that has guided every product I’ve worked on since that debacle back in 2007. #ProdMgmtHardLessons

The Most Important Thing You Need For Your Product To Succeed

Have you ever felt like there is no clear direction for your product?

That you keep getting jerked around building features to satisfy the latest customer opportunity?

That your product can do a lot of things, but it’s hard to articulate exactly what it does in just a few short sentences?

Maybe your product is trying too hard to be all things to all people?

Or maybe folks are constantly asking you why…

Why are we building these features?

Why are we selling to those customers?

Why is the customer wanting our product to do something else?

The reason for this often boils down to a simple truth:

The product lacks a coherent vision.

Having a product vision is quite possibly the most important thing you need for your product to succeed.

Yes, strategy is important.

Yes, execution is important.

But it all starts with having a vision for your product.

Without a product vision, how will you know where you’re going and why?

So every product starts with a vision to make it real. It’s foundational to the success of any product. It’s your north star. Without a coherent product vision, even a seemingly “great” product idea will fail in the market!

I decided to put my thoughts on this into a video.

So here it is. In it, I talk about:

  • What is a product vision.
  • Why it’s important.
  • How you can craft one for your product.

I cover this in depth in this video:

Creating a product vision doesn’t have to be hard. You don’t need to write some fancy vision statement, nor do you need torture yourself by trying to come up with the perfect elevator pitch.

You can actually start simply and immediately by defining four things:

  1. Who is your customer?
  2. What problem are you solving for them?
  3. What is your solution to that problem?
  4. What is your value proposition — i.e. that ultimate benefit you’re trying to deliver to your customer.

This is something you can do today. Right now. It can take less than 20 minutes. Even 5.

It doesn’t have to be perfect. It just needs to be done.

I talk about it in the video.

Over time, as you learn from the marketplace, as you learn from customers, you’ll refine the vision. That’s a good thing.

Watch the video, and when you’re done, please leave me a comment on what challenges you’ve had to face because your product lacked a proper product vision.

Then be sure to grab this quick fill-in-the-blank worksheet below to help you create the product vision for your next great product idea!

Grab Your Copy Of The Fill-In-The-Blank Product Vision Worksheet >>

Do You Have A Problem Worth Solving?

In order to pursue any product idea — a new product, or a new feature for an existing product — you must make sure it’s a problem worth solving.

If it doesn’t solve a tangible, real problem that lots of people are facing, and are willing to pay to have solved, it’s not worth spending your time on it. Move on to your next great idea.

So how do you go about figuring out if your product actually solves a problem that’s worth solving?

And what makes a problem worth solving?

In their book, Tuned In, authors Craig Stull, Phil Myers and David Meerman Scott talk about this in detail.

In order to know whether your product idea solves a problem that’s worth solving, it must it must satisfy the following criteria:

  1. Is the problem urgent?
  2. Is the problem pervasive?
  3. Are customers willing to pay to have the problem solved?

These three questions need to be answered before investing a ton of money or resources into developing and launching your product.

If the answer to any of these questions is “no”, then you need to pivot.

Let’s talk about each of these in turn.

Is the problem urgent?

Any product idea you’re pursuing must solve a problem people really care about. It needs to be a real pain point, a critical need, or a super important job for them.

The pain may manifest as costing them money, time, resources, effort, credibility, or some other significant inconvenience or frustration. Even perhaps emotional or physical pain.

The need or job could be social (look good, gain status, etc.), emotional (feel better, feel more secure, etc.), or functional (an important job that must get done).

If it’s truly a pain point or priority need/job, people will have expended time or effort to have tried to solve the problem. They may even have “hacked” together their own solution, or spent money on trying to solve it. This is what’s meant by the problem being urgent.

But why does this matter? Why is it so important to validate the urgency of the problem?

Because nothing is more frustrating than working yourself silly trying to solve a problem that either doesn’t exist yet or that people describe as “not a big deal”.

Here’s an example:

I hate taking out the trash.

I have to do it 2x a week, put it out on my driveway in the evening so the garbage truck can pick it up first thing the next morning.

I especially hate doing it in the winters when it gets really cold.

Is it a job I need done?

Most definitely!

Is it a pain?


But have I done anything to solve my problem?


I keep complaining about it. But I’ve done nothing to change the situation.

It’s just not a priority for me — it’s just not urgent enough.

As product people, we’re naturally wired to look for solutions. So we quickly and easily fall in love with our solutions.

(Thanks, Ash Maurya, for representing this first on your Lean Canvas.)

But we need to care about PROBLEMS.

So if you’ve got a product idea, you need to first care about your customers’ problems.

This is true whether you’re thinking about your next new feature or a wholly new product.


Customers don’t care about your solution. They care about their problems.

Just make sure the problem is an urgent one.

Is the problem pervasive?

The urgent problem needs to be one felt by a large enough number of people to make it worthwhile for you to develop and sell your product.


Say one product will cost $1,000 to make, and only two people in the whole world will pay you $10,000 each for it, and another product costs $10,000 to make, but 10,000 people will pay you $10 each for that one.

Which product is better worth your time?

Quite simply, if enough people aren’t experiencing the problem, then the market potential for your product idea isn’t big enough, and it’s not worth pursuing your product idea. Period.

Even for a new feature, you need to size the market opportunity for it.

Your company has a choice of whether to focus its resources on developing feature A or feature B. In fact, it has a choice of whether to have its resources focused on your new feature idea or something else entirely.

So no matter whether you’re pursuing a new feature or a new product, make sure it’s solving a problem that’s pervasive.

Are they willing to pay to have the problem solved?

This is critical — you may find a lot of people are complaining of the problem you’ve identified… but are they willing to pay to have it solved?

Most people have all kinds of problems that they’re just not willing to pay money to solve.

For example, I may whine about taking out the trash, especially in the bitter cold of winter.

And it becomes an urgent enough problem that I finally get my teenage son to do it. (Hey, it builds character.)

And lots of other people may be doing the same thing as me.

But neither they nor I are willing to pay to have someone come to our house twice a week to put the garbage out by the curbside.

Even for an existing product, a new feature must be able to create some tangible business value. Will customers pay for the new feature? Will the new feature justify a higher price for your product? Will it increase customer lifetime value, or accelerate new customer acquisition?

As long as you’re in a profit-making enterprise, it’s worth solving an urgent and pervasive problem only if the people with the problem are willing to pay for your solution.

Are you done? Not quite…

In order to decide whether to pursue your product idea or not, you need to consider a couple of additional things.

First, it’s possible that your company may have (likely has) a point of view (spoken or unspoken) on what it considers worthwhile revenue opportunities.

For example, at a $7 million company, a $50k opportunity could get the CEO’s attention…

…But at a $500 million company, anything less than $250k may not get much interest.

If so, it’s important to consider whether your product idea meets this threshold to be worthy of consideration.

Second, your product may have specific strategic business goals, such as driving new customer revenue, or generating expansion revenue from existing customers, etc.

If so, you’ll need to evaluate whether your product idea contributes in a meaningful way to achieving those goals.

In other words, is there enough monetizable value in your product idea?

If your product is currently generating $50 million in revenue with a goal to grow 15% in the next year, and you estimate your product idea could drive $500k in additional revenue, that means it will contribute less than 7% toward that goal.

Whether that’s good enough will depend on how it compares to other ideas that contribute toward achieving the goal, or whether it can be combined with other ideas in some rational way as part of a theme — then it will come down to how the theme in its entirety contributes toward the goal.

So to recap:

To pursue any product idea, make sure it’s a problem worth solving.

This means the problem must be urgent and pervasive, and your target customers must be willing to pay to have the problem solved.

Furthermore, your product idea must have enough monetizable value to contribute meaningfully toward your company’s strategic goals.

Fortunately, it’s not that difficult to learn how to do this. 🙂

The Secret Ingredient To Getting Product Innovation Done: “Internalvangelists”

So you’ve probably heard of “earlyvangelists”.

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

In Lean Startup circles, we hear a lot about finding these special breed of customers. Why? Because they’re the ones willing to make the initial bet on the startup, because they’ve bought into the startup’s vision and potential. They’re not just buying release 1, but the entire vision of the startup. This is what keeps them committed even if the startup screws up a few times.

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

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

Juxtapose this with traditional product management.

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

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

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

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

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

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

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

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

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

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

For example, the CFO needs to be able to answer a question from the Board like, “That $250,000 in development resources you spent last year… what are we getting for that?”

So a solid business case with cost/benefit, ROI analysis, risk profile assessment, etc., would allow for objective portfolio and investment decision making.

Good intent.

But here’s what actually happened.

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

“An exercise in pretend,” the product manager grumbled.

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

“Well, you need to figure it out,” Big Exec would shoot back. “Else, no resources for you!”

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

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

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

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

(Meanwhile, that Sales guy with his own “great” product idea has already sold vaporware to two customers and is magically getting resources assigned to deliver on his promise, including you, the product manager. Sales guy: hero. Product Manager: zero.)

The saddest part of all this was that every minute spent preparing the business case, writing the MRD/PRD or torturing the spreadsheet was valuable time not spent with customers.

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

#1 Biggest Innovation Challenge: Testing product ideas without having a product. With both customers and internally within their organizations. They need ways to test their understanding of the market, as well as evaluate the revenue potential for a product opportunity, but without having a product already.

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

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

How many people does it take to change a light bulb?

(Or maybe the question is: how many people does it take to get approval to change the light bulb?)

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

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

The internal venture must fight on a second front at the same time within the corporation. That second fight must obtain the permissions, protection, resources, etc. needed to launch the venture initiative, and then must work to retain that support over time as conflicts arise (which they will).
– Henry Chesbrough, Why Internal Ventures are Different from External Startups

#3 Biggest Innovation Challenge: Resources.

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

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

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

And, of course, this leads to the chicken-or-egg dilemma from challenge #1 — need a product to test whether customers value it, but need customer validation in order to get the resources to build the product!

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

So what’s the solution?

This brings us back to “earlyvangelists”…

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

  • Earlyvangelist customers.
  • Internal stakeholder advocates, or “internalvangelists”.

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

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

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

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

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

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

Here’s an example:

Customer learning driven investment strategy

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

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

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

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

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

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

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

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

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

The Keys To Productive Brainstorming


(c) Rob Cottingham, used via a CC BY-NC 3.0 license

Let’s face it: brainstorming has gotten a bad rap. And deservedly so.

How many of us have been part of a “brainstorming meeting” that turned out to be a total waste of time? Too many people. A purposeless agenda. Meandering conversations that go nowhere. And no follow-up afterward. Sound familiar?

In fact, doesn’t “brainstorming meeting” sound like an oxymoron?

The irony is brainstorming is actually an important tool to uncover creative solutions to thorny problems. Brainstorming broadens one’s perspective, allowing for new and unexpected ideas. It fosters collaborative thinking and the sharing of ideas, uncovers unexpected questions, and encourages creative exploration. These are important ingredients to fueling innovation.

If done well, brainstorming can be an invaluable tool for any product manager, entrepreneur or innovator.

So the problem really is that most brainstorming sessions are simply not conducted well. (OK, most are conducted really badly.)

So when Essay.Expert shared the following infographic on “Keys To Constructive Brainstorming”, with some useful tips on effective brainstorming techniques, it was a great reminder of how useful brainstorming can be if done right.

I particularly like tip #2 as it increases the likelihood of greater engagement during the brainstorming and continuity after.

Keys To Constructive Brainstorming

(c) Essay.Expert

What brainstorming practices have you seen successfully applied in your work?

10 Things To Do To Appear ‘Innovative’

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Why Products Fail [PODCAST]

Why do products fail?

What are the three important milestones for a new product?

Why is it so important to get to market fast?

How do you manage stakeholders when building a new product?

What is an MVP?

What are the key skills of a good product manager?

How do you stay in touch with current trends?

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

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

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


You won’t be disappointed!

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

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

Create Your Business Case Using Customer Development

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RIP PRDs. Long Live “Agile Conversations”

I don’t write PRDs.

Product Requirements Documents.

They take too long to write and are typically outdated by the time they’re “finished”, which, it turns out, they never are.

They’re never finished because the market changes. Customers’ needs evolve. Competitors change conditions. New technology changes everything.

Worse, they typically end up creating even more documentation.

Years ago, I worked in a company that followed a pretty typical waterfall process. Product Managers produced PRDs. (MS Word docs.) Big, multi-page docs that contained sections like “Product Overview”, “Business Objectives”, “Features”, “Personas”, “Use Cases and User Scenarios”, and a detailed itemized list of “Functional Requirements”.

Then Business Analysts translated them to “Functional Specifications”. (A bigger MS Word doc.) And then a System Designer translated those to “Technical Design Specifications”. (Yet another even bigger MS Word doc.)

Crikey, we weren’t building an aircraft carrier! We were just trying to build a software app.

Imagine if something had to change in the PRD? (Which it always did, of course.) That change had to get propagated down to each document.

More writing…

But here’s the funny thing: these documents never seemed to reduce the need for the humans involved in the project to talk to each other.

Each of these documents were typically followed by meetings. Meetings to discuss the very documents that were produced. To go over them page by page, line by line.

Going over such a large document takes time. So we’d schedule 3-hour, 4-hour, 6-hour meetings. (No kidding.)

But no one likes long meetings. So after a minor outcry, these meetings were reduced to 1.5 to 2 hours tops. The result was the poor Product Manager (or Business Analyst or System Designer) was now pressured to run through the same big document in less time.

Of course, it didn’t mean people had fewer questions, though!

So inevitably we’d run out of time and have to schedule a follow-on meeting to get through the rest of the document and answer questions we weren’t able to get to.

It’s not easy to coordinate the schedules of so many busy people…

Net was the original 3 or 4-hour meeting was now spread across multiple sessions that took place over several days or even weeks, and we ended up spending more time in total.

More time in writing and discussing documentation.

This could take weeks. Often, months.

And don’t get me started on the “change request” process!

And with so much time spent in writing and discussing the documentation, you’d think the output — the actual product that was delivered — was built as expected.


It was amazing how often, despite all the effort invested in documentations and meetings, some particular piece of functionality wasn’t delivered as originally envisioned.

So often it would be due to some disconnect between the various documents everyone was trying so hard to keep synchronized.

I swear, it would make me want to rip my hair out (of which I seem to have less of with age!).

We spent so much time producing, coordinating, verifying, validating, and CYA-ing the documentation that we didn’t do the thing that was most important:

Delivering value to customers as quickly as possible.

Our time is better spent interacting with customers, testing solutions delivering product to them, getting their feedback, and acting on that feedback as quickly as possible.

After going through this one too many times, I vowed never to do it again. That’s when I began experimenting not only with agile software development practices, but customer development and other lean strategies to test, validate and iterate on the business planning aspects of delivering software and digital products and services.

Over time, I’ve developed a more lightweight, human-friendly, and — yes — agile approach to testing, building and launching products. One that has a proclivity toward action and conversations, is fueled by customer centricity, and is predicated on delivering business value and speed-to-market.

To be honest, this approach isn’t particularly revolutionary, and I certainly can’t lay claim to having invented any aspect of it. It’s all pretty much what’s covered in the manifesto for agile software development, and the good news is these practices are being increasingly adopted in different companies and industries for different types of software products and digital initiatives.

And yet, every week I get an email like this:

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

People are increasingly aware of agile and lean practices. The agile manifesto is in the public domain. There are books on Lean Startup and customer development practices. But what this email (and countless others I receive) shows is that it’s one thing to be aware of a thing, and it’s another to actually put it in practice.

In fairness, that’s understandable. For one, people have different learning curves, in aptitude and even willingness to change. Old habits can die hard. There are also different environments, organizational structures and cultures to consider. Innovating in a startup is different than innovating in a global enterprise company. And then there’s special snowflake syndrome.

I’m on a mission to help as many of these product managers as I can. In my reply to this product manager, I shared the specific practices, activities and tools my teams and I use to replace the overblown PRD process. And I want to share them with you.

Here’s my reply (almost entirely copy-pasted here):

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

Ultimately what matters most is joint understanding between Product Management and Engineering (and Design, if you have it). If there’s a good relationship, all sides can come to an agreement on how the reqs should be delivered. And remember: regardless of how the reqs are documented, ongoing conversations between PM and Engineering is the key.

Are you still writing PRDs/MRDs? Or have you moved on to more effective processes? Share in your experience in the comments below.