5 Indispensable Habits Of Great Product Leaders

As a product management leader, there are many demands on your time. It’s easy to get sucked into working on the most pressing issues and on meeting other people’s expectations.

As “do-ers”, it’s in our nature to jump on these issues immediately. We pride ourselves on our competence to tackle these right away.

But when we do so, are we as product leaders really making traction on the things that matter? When you get to the end of the day, do you feel a sense of accomplishment?

We’re all familiar with the Eisenhower Decision Matrix:

Eisenhower Decision Matrix

Eisenhower Decision Matrix popularized in the self-help book “First Things First” by Stephen Covey

We know we should be spending more (most) of our time in quadrant 2, the yellow box.

I must admit, though, I’ve been guilty of spending too much time in the urgent column. Heck, I’ve wasted time being in quadrant 4.

There’s always a fire to put out, an urgent meeting, a request from up the chain to satisfy, someone stopping by the desk to ask a “quick question”, an email to answer, a phone call to return.

The problem is that while it feels like we’re getting stuff done in the moment, we’re actually not getting anything of real value done. It’s an illusion.

And we know this, because by the end of a day like this we usually feel drained, and lack a sense of real accomplishment.

This problem can be particularly acute for product leaders, who are responsible for (among other things) the product vision and strategy of the company, the business results of the company’s product portfolio, the performance of the product management process, and the success of their team.

The challenge is if we don’t make time for the important stuff, the urgent will always win.

But it’s easy to say we should spend time in quadrant 2. How do we actually do that?

Dan Martell, successful serial entrepreneur and investor, published this video on his YouTube channel in which he talks about what should the day of a startup CEO look like.

He talks about how as he grew in his career, he began thinking about how he could make time for the things important to him, and what are the things other people can support him on and help him with.

He lays out 5 things that startup CEOs should focus on. As I listened to this list, I realized that these same habits apply to successful product management leaders!

They’re habits because they do these regularly, every week, every day. It’s how they ensure they’re making traction on the things that are most important.

As I’ve grown in my own career, I’ve done these same things, and found them to be indispensable in the successful execution of my products.

Here they are:

1. The Daily Check-In

The most effective product leaders check in with their team every day.

Yes, every day. As much as is practical, do this at the top of the day.

One way may be in the form of a stand-up or huddle where folks provide a quick update on progress and highlight any major impediments to getting work accomplished.

Another way is to check in individually. You may “walk the floor”, stopping by each team member’s desk for a few minutes to see how things are going, how they’re feeling, and if there any major issues they may need help with.

As a product leader, you need to stay in tune with the “pulse” of your team. A daily check-in will enable you to stay on top of things tactically, as well as ensure you’ve got the temperature of your team members.

2. Keep Half Your Schedule Open For Strategic Stuff

What? Half? Really?

OK, so this one may be a challenge. But it’s SUPER important.

As a product leader, you’re responsible for setting the product vision and strategy.

That means spending time doing research, discovery and analysis, AND having some thinking time.

In addition, as a product leader, you’re responsible for communicating the product vision and strategy to everyone else in the organization.

So the point here is you need to keep a good chunk of time dedicated toward strategic activities.

If you think this is difficult, look back at the Eisenhower Decision Matrix, and ask yourself how you realistically plan to get quadrant 2 stuff done?

If you don’t make time for it, if you don’t protect that time, trust me, you’ll never get it done.

I’ve actually blocked time off on my calendar to do strategic stuff. I fight not to give up that time.

Keep half your schedule open for strategic stuff.

3. Major Projects Should Be On Your Calendar

This is somewhat related to point #2.

For example, you may be performing due diligence on a potential partner or acquisition as part of a developing product strategy. Or you may be conducting some market research or customer interviews.

Make sure these things are on your calendar.

In addition, there may be major initiatives either you are personally championing or that your team is working on that require your priority attention. A new product launch or a major release, for example.

If you want to get traction on these things, be sure to block off a reasonable amount of time for them — time that enables you to achieve flow.

4. Align Everyday Work To The Product Vision

In product management, it’s easy to get consumed by a particular feature, requirement, story, page layout, design construct, thorny technical issue, project delivery date, PowerPoint slide, or Excel analysis.

As a product leader, you need to make sure everyone understands their work serves a higher purpose.

That it ties back to something bigger, a shared goal. This is typically the product vision, product strategy, even the company mission.

And you need to do this constantly. All the time. Every day.

As Dan Martell describes it perfectly in his video:

“People forget. They get in these funks. They don’t understand why what they’re working on is going to be aligning to the bigger purpose. You should be going around to your team and saying, ‘Hey, you know that interface you’re designing? That’s going to allow us to do X, Y and Z, and allow us to achieve these big results we’re all agreed upon.'”

5. Talk With Customers. Every Week.

If you’re a product leader, this should be a “Duh!”

In fairness, though, it’s easy to become preoccupied with the demands of senior executives, the CEO, the Board, your peers, and your own team.

Certainly, the larger the organization, the more demands on your time from people within the organization than without.

But the primary job of product management is an executable product strategy. To do that means spending time with customers.

So it’s imperative product leaders dedicate time to hear directly from their customers.

Even if you have product managers reporting into you, perhaps an entire hierarchy with Directors, Senior Product Managers, Product Owners, etc. on your team, you need to spend time with your customers.

Not so much to get feedback on a specific feature or an interface design, but to immerse yourself in their world — what challenges they’re facing, what trends they’re seeing in their industry, what opportunities they’re pursuing, what defines business and personal success for them.

By doing this, you can not only make sure the current product vision and strategy, even the company mission, is aligned with the needs of your customers, but also identify opportunities to pivot on these things if necessary.

And it enables you to align the every day work with how you’re creating value for your customers.

Disclosure: I don’t know Dan Martell personally, but am a follower. All credit and many thanks for his excellent video in inspiring this post.

13 Myths And Misconceptions About Product Managers

The good news: when it comes to software, product management is now being seen as a legitimate profession and increasingly critical to a company’s growth strategy.

(Ok, maybe it was always thus in Silicon Valley, but the rest of the world is now catching up.)

The bad news: There are still many myths and misconceptions folks have about our profession.

Here are some common ones:

  1. Product Managers are proxies for project managers.
  2. Product Managers are “technical people”, so it’s not necessary to involve them in business, sales, marketing, pricing or (worst of all) strategic discussions.
  3. Product Managers are “technical people”, so naturally they define/understand the database structure, system design, server configurations, etc.
  4. A Product Manager is a “technical role”, so must sit under Engineering or IT.
  5. A Product Manager’s primary (only?) job is writing requirements…
  6. …And how hard can that be? (One of my favorite quotes from non-PMs: “I could write those requirements over the weekend.” Go for it, boss.)
  7. If the product has a technical issue, like something wrong with the data model, SQL stored procedure, or the system design, the PM is responsible and answerable. (Uh, no.)
  8. A Product Manager can come up with a product roadmap without a well-defined product strategy.
  9. A Product Manager can come up with a product strategy without a well-defined business strategy.
  10. A roadmap is simply a case of plotting a bunch of features on a timeline with dates. How hard can that be?
  11. The Product Manager must come up with delivery estimates and dates, and stay true to them no matter what. (Because we product manages are fortune tellers, of course.)
  12. The Product Manager must spend most or all of their time with the development team / in the scrum. (Nope. They must equally spend time, if not more, in the market.)
  13. The Product Manager is “CEO” of his or her product. (Nope. The CEO is the CEO.)

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.

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.

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):

 

Time spent is not a VOC quality metric

A CEO and I were debating whether amount of time spent with a customer is a measure of the quality of the customer interaction.

His argument:

Just curious — do you see 23 touches for 5 mins the same as 23 touches for 1 hour each — I think it is different and material.

From my perspective, I need to allocate a certain number of hours per week with customers and believe that number in a normal week is likely 5 hours. I am not sure if that is right, but 5 hours out of 40 per se seems about right. To me, a 3-hour dinner with a customer will be very revealing.

Time matters… Speaks to quality, don’t you think?

His assumption here is that there’s no meaningful insight to be gained in a 5-minute conversation. He’s also arbitrarily picked 5 hours per week. (Why not 4? Or 2? Or 8?)

My response:

Here’s how we should think about it.

Why are we seeking VOC? What’s the purpose?

At the most fundamental level, in any situation, there are three kinds of customer insights we’re trying to gain:

  • Problem Discovery
  • Problem Hypothesis Testing
  • Solution Hypothesis Testing

There are many techniques to accomplishing these. The specific ones we use depends on the situation.

For problem discovery, onsite customer visits or a series of 1-on-1 interviews are best. These take time. 45-60 minutes an interview across 10, 20, 50 customers, for example. An onsite visit takes time to schedule and could be 2 hours or 20 minutes depending on the customer’s availability and how deep one wants to immerse oneself into the customer’s world.

For hypothesis testing a broad problem domain, 1:1 interviews are often the best. So in this case, I’ll opt for 23 phone conversations of 30-60 mins each, because I know neither email nor a survey nor a 5-min phone conversation will provide me the richness of insight I need.

For solution hypothesis testing, it can vary.

If I’m validating a mockup of a potential solution the customer has never seen before, a 20-60 min interview may be needed.

In all the above situations, I want the richness of the fluidity of the conversation, have an opportunity to ask follow-up questions and feel the customer’s emotional responses.

But let’s say I’m trying to validate the need or usefulness of a specific feature — i.e., will it or does it solve a specific, previously identified customer problem.

In this case, using an email or an automated tool would enable 23 touches in 5 minutes, and work perfectly. I could do it via phone calls, which would have taken longer, but ultimately would have given me the same quality of insight.

Another example is having weekly meetings with the Sales team.

The meeting doesn’t eliminate the opportunity for a Product Manager to get on sales calls and demos. However, there’s great efficiency and value to these meetings, because in 30 mins I get buyer feedback across all our products from 9-10 folks who are making a large number of customer calls every day.

Which technique to use in any given situation depends on the type of VOC one is seeking, the purpose of seeking it, the ability to access the customer quickly, and the time available to seek and act on it. And in all cases reasonable judgment, of course.

With respect to allocating time for yourself to obtain VOC, that’s a different thing.

You’re a busy person, so it’s understandable you need to figure out how much time to allocate for VOC vs. other tasks.

But that’s solving your problem — i.e., your problem of time allocation.

It’s different than the how, what and why of obtaining the VOC itself.

And provides no guarantee of the quality of customer insight that you may gain.

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.

5 steps to validate your product idea without a product

Here’s a scenario:

Top Exec at your company comes to you and says, “Yesterday, I was talking to Big Industry Player and they mentioned how they have Shiny Object. I think we should have Shiny Object too. How fast can we get it done?”

Sound familiar?

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

During the session, we asked folks questions like:

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

Most folks talked about having some sort of governance structure, such as an Executive Steering Committee, to vet new ideas based on some established criteria. Many talked about the need to create a business case. Some advocated that Product Management is best suited to do that, regardless of where the idea came from.

Yet, after the session, every person I spoke with told me they felt writing a business case was a total waste of time.

What gives?

The old ways just don’t work

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

The problem is many product managers are never taught a systematic method by which to obtain the crucial information needed to inform a business case.

So what’s the solution?

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

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

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

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

The solution is validated learning

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

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

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

  • Formulate a testable falsifiable hypothesis.
  • Test the hypothesis.
  • Analyze results and learnings.
  • Decide to pivot or persevere.
  • Repeat.

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

1. Write down your customer hypothesis

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

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

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

2. Write down your problem hypothesis

What problems does your idea solve for the customer?

One way to do this is to think about the goal or job the customer is trying to accomplish.

For example: “I believe [customer] has a problem achieving [goal].” Or: “I believe [customer] is trying to accomplish [job], because [desired benefit].”

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

3. Validate your customer/problem hypothesis

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

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

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

A pivot is a fundamental change in direction of your business model or product strategy. You face a pivot when your hypothesis has been invalidated (i.e., proven false).

At this early stage, you could expect a pivot in terms of a change to your target problems, your target customer, or both. This may mean going back to step 1 or 2.

However, if the results of your test prove (i.e., validate) your customer/problem hypothesis, you may decide to persevere and move on to step 4.

4. Validate problem/solution fit

Now that you’ve validated your customer/problem fit, you need to test whether your idea is a potentially viable solution to the customer’s problem.

There are many ways to go about this, but nothing really beats creating a visual representation of your envisioned solution in the form of a wireframe or mockup. To keep things simple and minimize work, I look to design a representational screen or flow for each discrete problem identified on my Product Canvas and validated via the previous steps.

The primary goal of this stage is to garner early customers who endorse your solution vision and would be willing to use and pay for an early version of the product.

You’re also looking for directional feedback to identify the “right” handful of features to build for these early customers to prioritize your product development.

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

When done, just like you did at the end of step 3, analyze your data and decide whether to pivot or persevere. At this stage, you may pivot on the solution, the problem or even the customer.

Or, if you’ve validated your hypothesis, you may have problem/solution fit and can move on to step 5.

5. Validate your solution via an MVP

There are many misconceptions about what constitutes an MVP, and I’ve written about these before.

In short, an MVP is  an actual product that attempts to deliver real value to customers.

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

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

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

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

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