Product Management Ideas - Part 3 [Ever-Growing Free PM Book]

Disclaimer. These ideas are not mine. A lot of great people share their thoughts about different aspects of product management. I’m gathering the ones I find the most useful.

  1. Behind the scenes of product development: Building the perfect product
  2. The Secret Truth About Your Methodology and Processes
  3. Make yourself “Redundant”
  4. Your Role is not to Write Requirements
  5. Plan with Problems. Execute with Solutions
  6. Product Fail
  7. 3 Keys To Feature Validation
  8. Cognitive Biases & The Questions you Shouldn’t be Asking
  9. Tips, tricks, and hacks that help you to be a better, more clever, Product Manager
  10. Product Discovery is a Team Sport

21. Behind the scenes of product development: Building the perfect product

Behind the scenes of product development: Building the perfect product

Product success illusion

Dedication

What does dedication mean to you? In product development, it’s a near-obsession with creating your MVP. You give it your all, from putting in tons of time to an extreme focus on innovation and stick-to-itive-ness. If you had to choose only one trait to help you succeed, it should be dedication.

Dedication keeps you going in the face of failures, trials, and challenges. Because you will face those, sometimes in abundance. But by immersing yourself completely into achieving your goals, you can overcome.

Hard work

Hard work incorporates the self-discipline, the right attitude, and the ability to put your own needs last. If you can combine these three elements—and add in dedication—you’ll be on the path to achieving your highest potential. In fact, no one ever achieves success without hard work. Henry Ford once stated, “The harder you work, the luckier you get.”

Discipline

Discipline helps you and your team focus on what’s important and stay the course when challenges arise and failure happens. It also helps you avoid egos blocking creation of an outcome rather than an idea. Your outcome is an MVP that delights your customers. It’s not one person’s or even the team’s idea about what that product should look like.

Product development and design is more than just about the responsibilities of the designers and managers. When you limit yourself and your team to responsibilities, you limit the point of view and the opportunity to use a cross-disciplined set of skills and know-how. Think of the discipline of product management as planning’s more holistic evolution over the past several years.

Ongoing feedback & customer engagement

Have you run across this quote from Jim Barksdale, former CEO of Netscape? “If we have data, let’s look at data. If all we have are opinions, let’s go with mine.”

The above quote should make you stop and wonder for a moment: who or what is driving your team’s decisions? Is it continuous feedback from and engagement with your customers? If it’s not, you may end up with something different from what your customers want.

How do you really know which features and benefits are most important if you don’t ask your customers? Engaging often with your customers during sprints will help you focus on an MVP that won’t flop right out of the gate. If you want your product development & launch to be successful, this is one area you can’t afford to skimp on.

Disappointment

If a product succeeds, it’s a team win. If it fails, it’s more likely the product management’s fault. You and your team will face disappointments; they’re inevitable. You must be ready to get outside your comfort zone and attack disappointment head on. Your end goal is to make sure you don’t disappoint customers with your MVP.

Rewrites & revisions

Two of the biggest challenges you’ll face in product management are rewriting test cases and sorting out which elements stay and which go. In addition, moving forward without a clear picture of your end deliverable can cause hours of revisions, rewriting documentation, and more.

It’s nice for the team to tackle tasks that seem simple. But without adequate customer feedback and other data, what takes the team an hour to complete could run into 8 hours to rewrite and revise on the back end.

Still, some rewrites and revisions will happen despite your best intentions. Make sure your team gets the time and the support to rewrite and revise as necessary.

Sacrifice

One of the hardest things you may face in creating an MVP is sacrifice. If your company has competing goals, strategies, and objectives, you may find your product on hold while the company pursues another one. As a product management professional, it’s your job to keep your team motivated despite of sacrifices made.

You also must make sacrifices when you come across roadblocks. If the roadblock is big enough, you may need to sacrifice a popular feature to get your MVP out. And at some point, you will need to sacrifice perfection to release your product.

Failure

There are small failures that happen almost daily in product developement. When you talk more than you listen to your team, you’re failing them. And when you refuse to learn from other’s mistakes, expect failure to hit.

Then there are the big ones: product failure. This can happen for a variety of reasons, but when it does, it’s normally not one single thing. The key is to learn how to take failing products and transform them into customer delights.

Working with customers early and often is one way to avoid failure. Another way is to create a living, breathing product roadmap that evolves and grows as your product does. Your product roadmap can help you avoid surprises down the road.

Persistence

In fact, you need to become somewhat of a superhero. You work long hours, stretch yourself across various departments, and make plenty of tough calls. Above all else, you must be persistent in meeting or exceeding the various demands and requirements of those you protect and support.

22. The Secret Truth About Your Methodology and Processes

The Secret Truth About Your Methodology and Processes

A product organization has three overarching goals:

A product organization that achieves those goals is much more likely to be successful.

Your methodology, your process, is a means to an end. It’s not the end in itself. If it’s not helping you deliver on your goals, then you need to change it.

Our methodologies, our templates, our practices are all just means to an end. So, let’s come to an agreement on what our end goals are and only then talk about the best ways to achieve those goals.

What if you already have a process or a methodology? Well, you have to do the same thing. What are your real goals? Are your processes helping you achieve those goals, or are they hindering you on achieving those goals? If they’re not helping, you need to change them.

Your methodologies and processes are not sacred. If you treat them as sacred, but you’re not achieving your goals, you’re not going to be successful.

  1. Be sure you articulate your goals as a product organization.
  2. Assess your methodology and process, as it’s practiced. Is it helping you achieve those goals? Or is it hindering you?
  3. If your methodology or process is hindering you, what’s one change you can make immediately to align it better to your goals?

23. Make yourself “Redundant”

Make yourself “Redundant”

You should let your ego rest. It really doesn’t matter who makes the decisions as long as the decisions taken are the right ones. It doesn’t really matter whose ideas win, as long as the right ideas are promoted. Your job is to steer the ship in the right direction, utilizing the power of the wind and the waves.

On the short term, your goal should actually be to make yourself almost redundant. It means you have a great team that works with you and that you managed to build great processes with them. It enables them to not rely on you on the daily things and enable you to work on more strategic things.

You don’t want to make yourself irreplaceable on the short term. This will exhaust you and will result only in short term wins. You want to make yourself count and impactful for the long term. You want to be the one that takes an already great team that already delivers great value and help them focus even more and achieve greater things.

Unless your team is really understaffed, you are in a week in which you travel, meet customers, launch a product or attend a workshop, if you find yourself in your daily work not having enough time and chasing tasks around the clock, something is wrong.

If you spend all your time maintaining the backlog instead of thinking, researching and talking with your team and your users, it is time to wake up. If you say too much “I don’t have time …” to meet with college product managers, to read about the competition or other important stuff, to meet with your mentor, to think strategy, to learn more, to innovate in unplanned corridor discussions, or even just to stare at the wall and “ponder” about the future, this is the time to do something about it and make yourself more redundant.

There is usually no such thing as “I don’t have time …”. We all have too many things on our plate, and a product manager’s work is usually around the clock. It’s more about choosing the right priorities. It’s not different from prioritizing a backlog. Every time you choose something to do, there is something you have chosen not to do. Just like you need to learn to say “no” to features, you need to learn to tell yourself “no” to some tasks that are of less priority.

24. Your Role is not to Write Requirements

Your Role is not to Write Requirements

Your most important role is to be the “focus” advocate and to solve the customer’s pain. You need to make sure that all your team members row in the same direction and that all the right questions are asked. You also need to say “no” a lot. You need to make sure that you bring the customer and user’s point of view while keeping the technical and legal aspects of the product and the strategic goals of your company in mind.

The most important thing for you to do in all times in to try and understand what is the major thing that is blocking your team from delivering the right product as fast as possible or what is the next thing to do that will move the needle for your product. At different times it may be different things. It can be lack of clear strategy, lack of goals or metrics, lack of process or a bad process, lack of customer inputs, communication problems, lack of the right resources, and more. It can also be a need to introduce a totally new direction for the product’s user experience or expanding the product into new use cases or verticals.

Whatever it is, that is where you need to put most of your energy. Because no matter how good your requirements are, if something doesn’t work properly and you are not making big steps, your requirements don’t matter. As the red queen from Lewis Caroll’s “Through the Looking Glass” said “Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!”+

25. Plan with Problems. Execute with Solutions

Plan with Problems. Execute with Solutions.

It does not matter if the method used is Scrum, Kanban, or the hybrid Scrumban. You can be agile without sprints, and you can do sprints and still not be agile. As long as the team focuses on making only the execution process agile, the result may still be an only improved waterfall.

If product management makes long-term commitments of solutions to the business, and writes long specifications, which are later broken to sprints by engineering, the whole essence of agile is missed, and it just becomes a more effective waterfall. If you do too many detailed requirements, you fall in love with them, and you are not building a real MVP.

Agile Product Discovery

Agile culture should start with the executive team and product management, while agile process should be initiated by product management and engineering. It should follow the lean startup methodology, even if some small things need to be adapted to corporate culture.

It means that as a product manager, you should always iterate on what you do next, and re-consider your plan every sprint. It means you must involve your engineering team in the discovery process in order to innovate prototype and evaluate what may bring better value to the product and to your customers.

The team must first focus on what to do, and not just on how to do it. While they are both important, what to do has the most impact on product success.

Outcome vs Output

Execution is about output, and most agile teams measure themselves by velocity. While it’s very important to be efficient, it is a misleading metric. The statistics are very sad. A research by Standish Group claims over 64% of developed features are never or rarely used.

A product team should focus on outcome and not on output. They need to check whether the feature they delivered does what it was intended for. They should focus on the results. To properly do it, you need to ship it fast to customers, check its performance, and iterate on the solution, until the wanted outcome is reached. This process is usually referred to as Build-Measure-Learn feedback loop, a concept taken out of lean startup methodology.

Your plan ahead should be a set of KPIs and initiatives that communicate directly with the business goals. Once you have such a plan, you can iterate every week on how to solve things properly without breaking your commitment. It enables you to be autonomous, empowered, and aligned with the business.

Squads and OKRs

Squads are autonomous product teams that have all the resources they need to execute their business goal. Their goal is usually derived from the business and they are free to pursue it however they seem fit. An example may be a squad in Facebook who is responsible to increase the number of friends you connect to (because it increases the value you get out of Facebook). A feature such a squad may produce may be “friends you may know”).

OKRs stand for objectives and key results and are a way for the whole organization to define objectives transparently and measure itself. It is another way to make sure you focus on the goals and problems and not make a roadmap of solutions. In OKRs you tell the team what you need them to accomplish, and how the results will be measured, and let them figure out the best way to solve the problems.

Minimal Backlog Policy

Many things have been written about Zero Bug Policy and why it is effective. If you keep a bug you don’t plan to fix now, it just consumes your time. The time spent on prioritizing bugs could have been spent better.

Backlog is no different. The worst thing you can have is backlog items staying in your backlog for too long. You spend a lot of time revisiting them again and again, and when you finally decide it is time to implement them, you find out that what you wrote 3 months ago is no longer relevant and you need to rewrite everything. Usually because you have already done it, you also have less passion to do it again, and the end result is not as good.

Having too many items in the backlog also creates the tendency to think about what we already have in the backlog instead of thinking freshly about all the things we may need to do, which might not be in the backlog.

Keeping the roadmap at the problem level ensures that you work on the solution only when it is really time to develop it. It may be 2 weeks before for a small feature or 3 months before if it is a major user experience overhaul. Take whatever you need to properly define the minimal change (and not the maximal), but not more than that (always think MVP). Don’t start working on a feature going to be implemented 3 months ahead just because you may have the time now. Focus on strategy or customer interviews instead.

Just like zero bug policy, if you wrote a detailed specification for a feature and then not to implement it in the near future because priorities have shifted, it is sometimes better to delete it from the backlog instead of revisiting it again and again.

26. Product Fail

Product Fail

Let’s start at the top – the source of ideas. This model leads to sales-driven specials, and stakeholder-driven products. Lots more to come on this key topic, but for now let me just say that this is not the source of our best product ideas. Another consequence of this approach is the lack of empowerment of the teams – in this model they’re just there to implement. Mercenaries.

Next let’s talk about the fatal flaw in these business cases. Now to be clear, I’m actually in favor of doing business cases, at least for ideas that need a larger investment. But the way most companies do them, at this stage, in order to come up with a prioritized roadmap, is truly ridiculous. Here’s why. Remember those two key inputs to every business case? How much money you’ll make, and how much it will cost? Well, the cold truth is that at this stage, we have no clue on either of these, and we can’t know.

We can’t know how much money we’ll make because that depends hugely on how good the solution turns out to be. If the team does an excellent job, this could be wildly successful and literally change the course of the company. On the other hand, the truth is that many product ideas end up making absolutely nothing. And that’s not an exaggeration for effect. Literally nothing. In any case, one of the most critical lessons in product is knowing what we can’t know, and we just can’t know at this stage how much money we’ll make.

Likewise, we have no idea what it will cost to build. Without knowing the actual solution, this is extremely hard for engineering to predict. Most experienced engineers will refuse to even give an estimate at this stage, but some are pressured into the old “t-shirt sizing” compromise – just let us know if this is “Small, Medium, Large and Extra Large.”

But company’s really want those prioritized roadmaps, and in order to get one they need some kind of system to rate the ideas, so people play the business case game.

An even bigger issue comes next. Companies get very excited about their roadmaps. I’ve seen countless roadmaps and the vast majority of them are essentially prioritized lists of features. Marketing needs this feature for a campaign. Sales needs this feature for a new customer. Someone wants a PayPal integration. You get the idea.

But here’s the problem, and it’s maybe the biggest problem of all. I call this the “two inconvenient truths about product.”

The first truth is that at least half of our ideas are just not going to work. There are many reasons for an idea to not work out. The most common is that the customers just aren’t as excited about this idea as we are. So they choose not to use it. Sometimes they want to use it, but they try it out and it’s so complicated that it’s simply more trouble than it’s worth, which ends up as the same result – the users don’t choose to use it. Sometimes the issue is that the customers would love it but it turns out to be much more involved to build than we thought, and we decide we simply can’t afford the time and money to actually deliver.

So I promise you that at least half the ideas on your roadmap are not going to deliver what you hope. By the way, the really good teams assume that at least three quarters of the ideas won’t perform like we hope.

If that’s not bad enough, the second inconvenient truth is that even with the ideas that do prove to have potential, it typically takes several iterations to get the implementation of this idea to the point where it actually delivers the necessary business value. We call that “time to money.”

One of the most important things about product that I’ve learned is that there is simply no escaping these truths, no matter how smart you might be. And I’ve had the good fortune to work with many truly exceptional product teams. The real difference is how you deal with these truths.

Next let’s talk about the role of product in this model. In fact, we wouldn’t even really call this role product at all. It’s really a form of project management. In this model it’s more about gathering requirements and documenting them for engineers. At this point let me just say that this is 180 degrees away from modern product management.

It’s a similar story with the role of design. It’s way too late in the game to get the real value of design, and mostly what’s being done is what we call the “lipstick on the pig” model. The damage has already been done, and now we’re just trying to put a coat of paint on the mess. The UX designers know this is not good, but they try to make it look as nice and consistent as they can.

Maybe the biggest missed opportunity in this model, is the fact that engineering gets brought in way too late. We say if you’re just using your engineers to code, you’re only getting about half their value. The little secret in product is that engineers are typically the best single source of innovation, yet they are not even invited to the party in this process.

Not only is engineering brought in way too late, but the principles and key benefits of Agile enter the picture far too late. Teams using Agile in this way are getting maybe 20% of the actual value and potential of Agile methods. What you’re really seeing is Agile for delivery but the rest of the organization and context is anything but agile.

This entire process is very project-centric. The company usually funds projects, staffs projects, and pushes these projects through the organization and finally launches projects. Unfortunately, projects are output and product is all about outcome. This process predictably leads to orphaned projects. Yes, something was finally released but it doesn’t meet its objectives so what really was the point? In any case, it’s a serious problem and not close to how we need to build products.

The biggest flaw of the old Waterfall process has always been, and remains, that all the risk is at the end. This means that customer validation happens way too late.

You’ve hopefully heard of Lean Startup methods, which are very much at the heart of the alternative. The key principle is to reduce waste, and one of the biggest forms of waste is to design, build, test and deploy a feature or product only to find out it is not what was needed. The irony is that many teams believe they’re applying lean principles, yet they follow this basic process I’ve just described. And then I point out to them that they are actually trying out ideas in one of the the most expensive, slowest ways we know.

Finally, while we’re busy doing this process and wasting our time and money, the biggest loss of all usually turns out to be the opportunity cost of what the organization could have and should have been doing instead. We can’t get that time or money back.

27. 3 Keys To Feature Validation

3 Keys To Feature Validation

Clarify the business rules

Where development (and feature validation) tend to go awry is when you’re not quite sure what problem you’re solving. Before prototyping, discuss the market problem with your team and be clear on the business rules: What are the needs? What are the constraints? What are the outcomes?

Needs, constraints, and outcomes are the basis of acceptance testing. Clarifying these will guide the design of the prototype or feature. Does the prototype or feature do what it should? Will it deliver the desired outcome?

Use “hallway usability testing”

Feature validation doesn’t have to be a massive effort. As soon as you see a prototype, you may immediately like the implementation. After all, you’re a customer representative. But if you’re not sure, show it to some friendly colleagues and customers.

A hallway usability test is where you grab the next person that passes by in the hallway and force them to try to use the code you just wrote. If you do this to five people, you will learn 95% of what there is to learn about usability problems in your code.

Share prototypes with key clients

In your customer discovery, you should have built a few friendships with your customers. People you’ve learned to respect. Give them a call and describe what you’re planning to build. Set up a screen sharing session and show them the prototype. Listen to their feedback and write down every sentence that starts with “Will it…?” or “Can it…?” or “I thought it would…” (and especially, “Hmm, that’s interesting.”)

It’s critical to do validation with people you trust. Clients who won’t share your ideas with competitors (or even with your sales people). Clients who won’t mandate a deliverable based on what they’ve seen. After all, you don’t want them blogging about it or making it a contractual commitment. Remember: a prototype may never be built. It’s a representation of an idea that may not be delivered.

28. Cognitive Biases & The Questions you Shouldn’t be Asking

Cognitive Biases & The Questions you Shouldn’t be Asking by Cindy Alvarez

Confirmation Bias

With confirmation bias, we look for evidence that proves us right, and avoid or ignore evidence that contradicts our beliefs. We don’t do this on purpose, but it happens. Instead of asking “How likely would you be to use (a solution)?”, ask “Tell me about what you’re currently doing in (a situation).” Hearing people’s stories is better way to discover what they really need and what they really care about.

Cognitive Dissonance

Cognitive dissonance is the feeling when we’re trying to hold two contradicting views at the same time. When research is not proving what we thought it would, it is tempting to ask, “Are we sure we’re talking to the right customers?” This helps us feel better by saying it’s the users fault, not ours, but it’s not solving the right problem.

Do not ask Are you sure we’re talking to the right customers? Instead, start by saying, “Let’s assume (an undesirable belief) is true. Now what?” Just the semantic break of pretending something is true lets our brains release and helps us get to a different answer.

Survivorship Bias

We want to talk to happy customers because it makes us feel good. This is the heart of survivorship bias, or “Happy Customer Bias.” But your happiest customers are not typically the best representation of what needs to change in your product.

Instead, talk to churned customers, low-usage customers, or non-customers using competitor products. Talk about what drove them away or why they’re not using it. Ask them questions like, “If you HAD to change one thing…”, “Which tasks do you put off doing?”, or “How have you done (a task) differently in the past?”

The Curse of Knowledge

Once we have a fact or skill, we cannot remember what it was like to not have that fact or skill. So the people who have used your product for a long time don’t know what it was like before they started. We’ll often ask “How hard was it to get started with (a solution)?” and you’ll hear people say, “It wasn’t that hard. I figured it out.”

Instead ask, “Suppose you had a new coworker join your team – what advice would you give them to get started?” People will immediately start telling you all of the difficulties and workarounds they have to implement to use your app. When you ask in this way, people don’t feel like they’re criticizing you, they feel like they’re helping a friend.

Social Desirability Bias

When you ask people, “How often do you go to the gym?”, many will say 5 or 7 days a week with a straight face even if they only wish they exercised that often. This is social desirability bias – we (unconsciously) edit what we say to make ourselves look good. So think about if your questions have a socially-preferable answer that might bias your results. For example, “Do you have a hard time meeting deadlines?” Who wants to say yes to that?

You would get more honest information by asking, “In the past month, tell me about a time when you got something done later than you originally promised.” We give people permission to admit to faults, which helps us see problems to solve.

Backfire Effect

The backfire effect – presenting rational evidence against our beliefs can make us reject it, and believe in our original thought even more strongly. Or put simply: you can’t fight feelings with facts. If a customer thinks they need a feature, you can’t convince them otherwise.

To manage the backfire effect, don’t tell someone “You’re wrong.” Say, “You’re right – and…” Nothing deflates a fight better than “you’re right” or “I’m sorry.”

Get to the Real Answers

Some key questions that will help you understand if your customers truly need what they are asking for:

These types of questions help you understand if there are actually problems to be solved and if the features your customers are asking for are really needed, or if they are just things that are nice-to-haves that can be removed from your roadmap. Asking questions in the right way will help you avoid biases, understand your customers better, and build the things that are really needed to solve problems.

29. Tips, tricks, and hacks that help you to be a better, more clever, Product Manager

Tips, tricks, and hacks that help you to be a better, more clever, Product Manager.

30. Product Discovery is a Team Sport

Product Discovery is a Team Sport

It’s critical that your team buys in on the vision and strategy for your product. This is a prerequisite for getting started on discovery with the whole team. If they don’t know why or what they’re trying to discover, they’ll resent you for wasting their time. The team should have a clear idea on the types of users they’re going after. They have to know the metrics they’re aiming to impact. And they need to understand how it all ties up to company vision. These are table stakes, folks.

Don’t be afraid to spend ample time with the your team on this early and often. Of course, kick-off meetings and slide decks are often effective tools. But nothing solidifies product vision quite like hearing customer problems from real users.

If you’re fortunate enough to be a 100% co-located team, sit together every single day. Use the damn whiteboard walls! Talk through what you’re learning and brainstorming what’s next. If your team is remote, schedule a daily discovery recap call during heavy phases of discovery. Full team discussion and debate after interacting with a user is invaluable.

There can still be anxiety from not delivering production code. There’s always plenty of user research and design to do. But it’s important to leverage your team’s technical skills during this phase. Not only does this help reduce their anxiety, it will have a huge impact on discovery.

The team can learn the most when we build lightweight proofs of concept or prototypes. These often need developers to whip something up technical. These prototypes will never see the light of day and may create some throwaway code. But no doubt the time and resources are always well spent. This can help the project dash from assumptions to validation over and over.

Go to Part 2 and Part 4

Comments

comments powered by Disqus