Category Archives: 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.

Result?

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 Top Strategies For Doing Customer Interviews That Get You Real Insights

We all know a core responsibility of a product manager is to constantly and consistently bring the customer perspective into the business.

That means customer interviewing is a critical skill for every product manager.

I must admit, earlier in my career I totally sucked at it.

I had no plan. I often just winged it. I asked the wrong questions. I was a poor listener. I talked more and listened less. I tended to get too excited about my product idea and go into pitch mode instead of focusing on the customer’s problems. And I was very guilty of confirmation bias.

Fortunately, with lots of practice, over time I got better. As I did, I accumulated a list of the best strategies that I use even today to conduct an interview that helps me extract real customer insights.

Get the Entire List of 25 Customer Interview Strategies >>

So in this video I share 5 of the best customer interview strategies:

Use these 5 powerful tips to supercharge your customer interviews to extract every ounce of goodness from them:

  1. Set an objective. Know what you want to get out of the interview — that is, what is it you want to learn and come away with?
  2. Have a script. Having a script will help guide your interview with the customer, be better prepared and purposeful in your interviewing, and make sure you achieve the objective you’ve set out.
  3. Ask “Why?” — a lot. This is by far the most important question in your arsenal. It allows you to go deep, get inside the mind of your customer, understand their motivations, get to the true nature of the problem they’re trying to solve, and how they actually value their solutions.
  4. Ask for examples. Asking for an example forces your customer to get specific rather than speak in generalities, giving you tangible evidence of a customer’s problem, and allowing you to momentarily “live in their world”.
  5. Focus on listening. Cannot stress this enough! The biggest thing you can do is to TALK LESS AND LISTEN MORE. Your purpose is to get THEIR perspective — not promote your point of view, explain yourself, defend your idea or debate. The only times you should look to speak is when you need to clarify something or need to ask a follow-up question.

Get the Entire List of 25 Customer Interview Strategies >>

Follow these strategies and you’ll become a pro at conducting truly insightful customer interviews.

Watch the video above, download the full list of customer interview strategies, and please share in the comments below what strategies you’ve developed to conduct truly insightful customer interviews.

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?

Yes!

But have I done anything to solve my problem?

No.

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.

Remember:

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.

Why?

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. 🙂

How To Streamline Your Product Development Process

By Emily Hunter

Many businesses are sustained and driven by product development. From small businesses to multinational corporations, the creation of new products is vital to market survival, especially in a world where trends, likes, and dislikes appear to change on an almost daily basis. Because of the swiftly changing market, many businesses have looked for ways to make the standard development process a little faster, or at least a little smoother.

In standard product development, there are several stages in the process like idea generation, screening, commercialization, and so forth until the product is finally ready for launch. While this development process works well, and is still in use by a great many organizations, it doesn’t always foster quick change and a fast development cycle.

A Holistic Emphasis

Holistic processes, used by major companies in the United States and Japan, do not get rid of a company’s stages of development, but merge them. When the idea is born, for example, it might move through the development team before the screening team compares and contrasts it with new product-related ideas, but both ends work in conjunction with one another. Instead of moving through incremental stages, everyone simultaneously contributes until the product is done.

Today, when a product needs to be built before the next big thing comes along, flexibility is a must. Having more hands on deck during product development requires more trial and error than the standard linear method. However, it also necessitates more communication between departments, which fosters transparency and openness through every level in a company. Once everyone understands what the other departments do, they are far more likely to take advantage of cross-departmental collaboration, allowing the company as a whole to reap the benefits of teamwork.

A Little Push

As always, development begins with an idea. In many cases, it’s a very broad idea — one that requires limits to be stretched and tested. When ideas arise in big companies, they are usually generated and imposed from above, unlike small companies, which can think big and aim for something they’ve never tried before. The problem with “thinking big” is that big ideas are often daunting to execute in real life.

Naturally, the idea has to be feasible. It also has to have a time limit. It’s going to be challenging, so everyone involved will have to be pushed a little — by themselves, by management, by the other members of their team. Enforce deadlines, maintain high standards, and monitor the quality of work, but do so within reason. Too much pressure can destroy a team, but just the right amount can drive people to achieve accomplishments they never believed possible.

A Team of Their Own

Product development teams tend to be extremely independent. Basically, they are given a concept, and they build a design around that idea. If the people involved are qualified in their specializations, the project will gain a life of its own. If upper management is involved in starting this kind of team, they should remember that such an arrangement works better if they just stay out of it. Shifting already established parameters as the potential to destroy the entire process.

Over time, the team will develop its own personal goals in an effort to complete the task in the time allotted, often fostering a strong sense of unity through the shared task. In effect, management won’t have to move the goal posts because the team will do this on their own. With each victory inspiring them to further success, every challenge overcome will instigate another even more difficult challenge in a kind of snowball effect.

Streamline Appropriately

The process of streamlining product development is great for many companies, but it is not for everyone. A freeform creative process tends to involve a great deal of overtime. For instance, a team that is not willing to put in the extra creative hours to bring an idea to life would be better off with the standard, more stratified process. Likewise, the naturally unstable and flexible teamwork setting of a holistic development process is not conducive to a huge project involving hundreds of people.

Some companies are run by a single individual who basically invents the products on his or her own and then gives the specifications to a design team. In this cases, it’s best to simply design the product as ordered rather than trying to improve upon the design.

Dealing with Change

It’s not easy to do something different from the standard procedure, especially the “old way” is deeply engrained into a company’s routine practices. However, change is often necessary. A new streamlined product development process may feel a little strange at first, and it may seem like it’s not quite working, But every new process takes some getting used to. Whether it’s a new software program or new machinery, mastering an innovative new process typically produces fantastic results.

Emily Hunter has been writing about business topics for many years, and currently writes on behalf of the product development specialists at Pivot International. In her spare time, she cheers for Spirit of Atlanta, Carolina Crown and Phantom Regiment, creates her own sodas, and crushes tower defense games. Follow her on Twitter at @Emily2Zen.

Why Products Fail [PODCAST]

Why do products fail?

What are the three important milestones for a new product?

Why is it so important to get to market fast?

How do you manage stakeholders when building a new product?

What is an MVP?

What are the key skills of a good product manager?

How do you stay in touch with current trends?

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

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

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

 

You won’t be disappointed!

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

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

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 may seem perfectly reasonable, it’s misplaced at such an early stage. The question about architecture and tools may also seem perfectly reasonable on the surface, but it’s a scale question, and is not the right one to be focusing on before you know if you’ve even 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. 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 may 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.

Doing that so early is a waste of time, though. 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?

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 early adopters to whom you can 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.

After delivering this minimum viable product (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 (1) get these customers to stick, and (2) 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 and 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. You may uncover opportunities to evolve your sales messaging and positioning. You may also uncover feature gaps. If so, you can put the into the backlog as well to earmark for further validation. Pay particular attention to customer 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. 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.

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 expansion revenue — i.e., greater revenue from existing customers — features that drive engagement and up-sells may take priority.

Make some allowance for operational issues. You may not necessarily have a scale problem yet, so these type of issues should not take precedence over VOC or driving revenue; however, you 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 and business value vs. feasibility. Now you’ve got a validated product in the marketplace with a decent first-pass roadmap that you can build upon. Go forth and conquer!

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.

Nope.

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 Aha.io 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.

The Dirty Dozen Product Roadmap Roadblocks

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

By Bruce McCarthy

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

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

What Is A Product Roadmap?

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

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

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

The Dirty Dozen

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

1. No Strategic Goals

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

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

2. Focusing on Features

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

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

3. Inside-Out Thinking

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

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

4. One Size Fits All

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

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

5. Trying Too Hard to Please

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

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

6. Playing Catch-up

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

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

7. Not Getting Buy-in

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

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

8. Prioritizing on Instinct

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

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

9. Being Too Agile

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

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

10. Being Too Secretive

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

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

11. No Buffer

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

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

12. Over- or Underestimating

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

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

AN INVITATION

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

Use your product powers for good.

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

Original article can be found here.

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

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

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

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

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

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

Setting Strategic Goals

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

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

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

Objective Prioritization

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

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

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

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

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

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

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

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

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

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

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

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

Shuttle Diplomacy

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

When you practice shuttle diplomacy:

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

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

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

This means Stakeholder Development. And that requires shuttle diplomacy.

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