Month: April 2016

Categories
Product Management

An Incomplete Roadmap is Better Than No Roadmap

You will reduce cross-team confusion and increase clarity by publishing your roadmap right now.

Creative people are notorious for not sharing their work because “it’s not ready yet”. For product managers, they are typically referring to their roadmap. It’s difficult to ship something that you don’t think is perfect – especially when it’s the strategic plan for your squad.

I’m guilty of it, too. It’s a little daunting to think that you will be held to your roadmap. What if it changes? What if we don’t actually get to that work in the second quarter? What if someone doesn’t agree with the order?

But having a roadmap publicly available, regardless of “finished state”, fosters communication and makes it possible for other teams to begin aligning with you – which is a great thing for your product.

How will sharing your roadmap doc help other teams today?

  • You drop your roadmap doc in another team’s Slack channel. That team notices that you’re not planning on addressing Feature Z until way later than they were expecting it, so they start a conversation with you.
  • You have a 1:1 with your customer support manager about your mid-term roadmap plans. He sees that Feature X is scheduled for later this year, so he instructs the front lines to tell customers that it’s coming later this year. (or better yet, your CSM works with you to campaign for higher priority in your backlog!)
  • A PM from another team is surfing Confluence late at night and notices that User Narrative Y is not being addressed on your roadmap, so they tackle it themselves

Without a roadmap, all of these cases end in team mis-alignment, confusion and false assumptions.

Ready to publish your roadmap? Things to remember:

  • The content is more important than the format. Get something out there today and format it tomorrow. Here’s my roadmap template that you can copy if you don’t even want to think about format.
  • If it’s not discoverable, it’s might as well not exist. Share it wide and share it proud. Drop the link in some Slack channels. Create a video and include it in next week’s Product Update Videos. Link to it from your team’s wiki.
  • Your roadmap is almost always a little out of date. Everyone knows it. That’s fine. No PM is going to “hold you to your roadmap” if you’re pro-active about communicating changes to the effected parties. You should always do your best to keep this document as fresh as possible, but I would suggest updating the doc live in your grooming/strategy meetings and choosing “save and notify watchers” when you do make a change.

Go ahead, pull the trigger. Whether it’s Confluence, Trello, JIRA or an Excel spreadsheet, write out your roadmap and start sharing it around. You’ll be amazed how quickly things come into focus.

Categories
Product Management

Format Your Roadmap Differently to Foster Cross-Team Alignment

You’ll help foster cross-team alignment with less meetings simply by formatting your roadmap document to include what your team is working towards, and more importantly, why it’s important.

These are the five key areas of a roadmap document that make it possible for anyone to quickly understand your team’s plans:

  1. State your long-term vision in one sentence. This gives your roadmap the context necessary for someone who may not be intimately familiar with your team’s goals.
    • Be aspirational, not prescriptive: “Be the most used web mail platform in the world” is more aspirational than “Launch a webmail platform using Node.js in 2017”.
  2. State the top three problems your team is currently addressing. This helps your reader understand what are the most important blockers to achieving your ultimate vision.
    • Be descriptive, not prescriptive: “Our current offering isn’t considered reliable enough to run a company’s primary email system” is more descriptive “Our current offering is too slow”.
  3. Explain why these problems are the most important problems. All products have problems. This is where you get the reader to understand the scope of these problems, and why you are solving these right now.
    • Be specific, not generic: “The #1 reason businesses don’t convert to paid accounts is because their email is delivered in a reasonable amount of time. Our strategy to $1mm in revenue relies on 90% conversion to paid, and today’s conversion is in the 40’s” is more specific than “Fast delivery is necessary for a good email system”.
  4. Identify how you’re addressing these problems. This is the tactical part of every roadmap that everyone’s familiar with: the list of work to be done.
    • Be prescriptive at first, then get more and more aspirational: The top of your list should be very specific (“ability to compose a message in a new tab”), while the bottom of your list should be relatively undefined (“Native Android app”).
  5. Associate extremely rough timeframes with each solution. Attaching rough timeframes is strictly to help set the reader’s expectations. This is useful for your team to know what’s coming later, and for other teams to determine how to roughly align with you. Actual planning and alignment should not occur from your roadmap alone, so don’t overthink this.
    • Your roadmap is about direction, not speed: Remember that your roadmap is not a project plan. Like a literal road map, it’s primarily purpose is to indicate the direction your team is planning to go, and not how fast you plan to get there. Use relatively generic terms like “near-term, mid-term, long-term and someday” instead of “this week” or “this month”.

Finally: Don’t overthink it. An incomplete roadmap is better than no roadmap. I made this example roadmap to get you started. Feel free to copy and replace it with your actual roadmap and start sharing it as quickly and broadly as you can. You’ll start seeing the results in your very next meeting, promise.

Categories
Product Management

3 Simple Product Metrics

I think you can boil down all of your product decisions into three key metrics: stability, simplicity and speed.

It sounds simple, and it is. But whether you’re writing key results for your OKRs or naming epics for project planning, you will get your entire team on board quickly by suggesting that you focus solely on metrics that quantify stability, simplicity and speed.

Here’s why: when I was a junior developer, I had a VP of Engineering tell me that it was really easy to figure out how what order to build a product’s features in: “make it work, then make it pretty, then make it fast”.

Users will forgive a reasonable amount of slowness, but will just stop using your product if it doesn’t work for them.

That actually makes a lot of sense. If it doesn’t work, nobody will use it. If it works but it’s a pain to use, your user will use it begrudgingly, get frustrated and switch to a competitor as soon as one exists.

If it works and it’s usable, by the time you’re ready to be worried about speed, you’ve proven that you can build an elegant solution to your customer’s problem.  (and you better be working on speed at this point!).

If it works and it’s usable and it’s fast, nobody will stop you.

 

Categories
Product Management Tech

Your Customers Don’t Mean What They Say

Ask any customer at any point what they want, and they will tell you exactly what they want. And while they’re always right, you shouldn’t listen to them.

Your customer has a very specific context: themselves. Sure, that customer may tell you that they work in technology or even that they’re a product manager at their company. It will be tempting to write down the story exactly as they tell it to you and put it in your backlog, but you should resist the urge.

As a good product manager, part of your job is to understand a few key contexts: the company’s goals/mission, your team’s strengths and weaknesses, the abilities of the technology available to you, and your customer’s problems.

If your interviews are anything like mine, you probably hear a lot about your customer’s solutions to their problems at first. This can be extremely valuable for your knowledge, but building your product from their work-arounds is short-sighted.

Your customer is missing the things that make you a good product manager: wider context about your entire product. They probably don’t know the five-year goal of your company. They don’t know about the conversation you just had with your team. They don’t know that you’ve got a great designer starting on Monday.

Good product managers know that interviewing your customers is a basic requirement. (And there are lots of opinions on the Internet about interviewing your customers, this piece included.) But what’s the point if you’re not supposed to listen to them in the first place?

Maybe you’re asking the wrong questions. From Product Talk:

Instead of asking, “What matters to you when buying a pair of jeans?”, start with, “Tell me about the last time you bought a pair of jeans.”

Instead of asking, “How often do you go to the gym?”, ask, “How many times did you go to the gym last week?”

You can follow up both with a question like, “Is that typical?” This can help surface if the last time was unusual. If it was, ask about other instances.

It feels counter-intuitive, but it’s actually a great way to start down the Five Whys path.

Asking these kinds of better questions gives you the piece that you’re missing from your context map and will help you better understand the people that are using your product.