Month: May 2016

Development speed is important, but make sure your primary focus is on the result.

There was a contest where contestants had to find a box in a forest based only on a photograph of an item. There were two contestants. One was a spry young man who has never been to this particular forest. The other was a limping 60 year old woman who has lived nearby and knows these woods like the back of here hand.

The pistol fires and off they go. The young man takes off running. He runs here, runs there, runs circles, looking for something familiar from the photo. His endurance is uncanny and his ability to jump across branches second-to-none.

The lady looks at the photo and studies it. After a few minutes, she takes her walking stick and limps off. She recognized the rocks in the photo and knows more or less where to go to find the box.

The young man is much more productive in “miles ran per hour”, or “acres searched”, or in “O2-consumption-per-mile” metrics. For the lady, the above metrics are dismal.

However, she beats the man in the most important metric: “boxes found”.

It’s tempting to track how much work your team is putting out. Your team could be writing the most lines of code (“miles ran per hours”), or closing the most defects (“acres searched”), or deploying the most stories (“O2-consumption-per-mile”). But if those changes don’t affect the one metric that matters (“boxes found”), then you may want to reconsider what metrics are worth tracking.

Product managers can effect change today by using the same techniques that effective executives use.

Effective executives are great at playing politics. They’re continuously in meetings with decision makers, stakeholders and other teams to ensure that their idea is bought into and successful.

But executives don’t call it playing politics. They call it collaboration – and this is the key to getting things done when you need buy-in from people who don’t report to you.

Product managers are in a similar position. While we’re not CEOs (despite what the Internet wants you to believe), product managers are responsible for the ultimate output and typically don’t have direct line responsibility for the people doing the work. I heard someone describe being a product manager as “all the responsibility with none of the authority”.

Effective executives don’t dictate what to do. They get people on board using a combination of persuasion, collaboration and tact.

Since product managers usually don’t have the ability to hire and fire our team members, we need to rely on the same techniques that effective executives rely on to get a team of people to do the right work at the right time:

• Persuasive executives (and product managers) don’t have all the answers, but they know all the problems. When collaborating with another team, come to the table with crystal clear problems instead of answers. Engineers and designers are paid handsomely to solve problems, so unleash them on it. Not only will they use their brainpower to solve the problem, they’ll feel ownership over the deliverable (instead of pushing back against your solution out of ego).  BONUS: this is a great example of getting out of your team’s way.
• Collaborative executives (and product managers) add value to other teams. Whether it’s offering to let another team borrow an engineer to get that feature deployed or creating the slide deck for an upcoming group presentation, collaborative managers add value to other teams by offering to help however they can. BONUS: It’s so common in our profession for the default answer to be no, that you may garner good-will just by offering.  
• Tactful executives (and product managers) make sure nobody is surprised. Have quick, informal meetings with individual members of your team before announcing a change to the larger group. These short “pre-meetings” let you receive and react to feedback privately while showing that you care enough about their opinion to ask for it before finalizing your plan. By the time you’re ready to announce the change publicly, literally nobody is surprised. You’ve now successfully steered conversation at the announcement meeting to how it’s done, and not whether it’s a good idea. BONUS: These are great topics for conversation in 1:1’s with your team.

Thanks to fellow product manager Stephan Rubin for reading an early version of this.

Your roadmap is about direction, while your project plan is about speed.

Roadmap: where are we going and how do we think we’re going to get there. This is primarily driven by business strategy. (see: How to format your roadmap to foster cross-team alignment)

Project plan: when should we get there. This is primarily driven by resources and velocity.

It’s easy to conflate your roadmap with a project plan, but they are fundamentally different tools that are essential to creating your product backlog.

Focusing too much on the possible makes it improbable that you’ll solve the impossible.

As a product manager, it’s easy to automatically scale back the discussion to what’s possible. After all, you’re the one responsible for the timeline, the cost and ultimately the success of the outcome. So, it’s safer to push something good out now than to push something amazing out in three months.  “Nobody ever got fired for buying IBM”, they say.

However, you should come into the strategy session with the craziest idea to make your product better, and then let your team talk you out of it.

To experience real product growth, spit-ball those crazy discussions with your team. Don’t accept that “it works this way and it’s too hard to change” (especially when you’re the one saying it!). Talk about why it’s that way, how to work around it, ways to make it better, and what you would do with infinite time and resources.

Your team will only think as big as you do, so push yourself to think bigger. If you come in with constraints and excuses, you’re handicapping some talented, expensive creative talent.  The alternative is shipping small iterations (“quick wins!”) in the short-term, and that’s neither fun nor effective.

In an ideal world, you’d make an informed product decision backed by data, feedback and intuition. But you can still decide with only two.

If you only have DATA + FEEDBACK: your customer base is telling you something that surprises you. You’re solving their problems today, but make sure you’re considering the bigger picture. Dig into that data to validate the feedback you’re hearing and to predict the problems they’re not telling you about. You should understand what your gut is telling you and try to figure out why it’s not aligned with the data.

This week: spend some time getting a better understanding of your market. Install Intercom and contact leads that didn’t convert to understand why.

If you only have DATA + INTUITION: Your computer is telling you something different than you’re hearing from you customers. Don’t discount this immediately. Your customers may not know what they want, or you may not be asking the right interview questions.

This week: build an MVP with Invision or Squarespace, and attempt to validate it with your personas.

If you only have FEEDBACK + INTUITION: You’re certain that you’re onto something, but the skeptics don’t believe you. You’re either on the cutting edge of a breakthrough, or you’re way off in left field. Is it because your data is garbage, or you just don’t have enough?

This week: send an NPS survey or add Mixpanel tracking to quickly (and objectively) validate what you’re hearing.