Product Management vs. Dates

If you are out reading product blogs, following product folks on Twitter or researching product management apps, you’ll inevitably come across an article about roadmaps and the evils of date driven product development. Decades of bad software experiences have made this an easy topic for people to get fired up about. In fact, you have companies like ProdPad (which I’m a huge fan of) be quite proud of the fact that they don’t allow you to use dates in their application (which I’m not a huge fan of). This is a natural market reaction – find something really bad and then overreact with an equally extreme, but opposite solution.

Look, I get it, for far too long, product managers have had to answer the question “When will you be done?” and then they are measured and rewarded on their ability to launch software, even when they know it won’t actually solve the problem of their customer. That’s a crappy world to live in and it’s one that we should all fight against. The good news is that most people know that we should be focused on outcomes and driving value vs. hitting dates now. With that said, Dates Matter and are real factors in product decisions. Let me give you an example:

Let’s pretend we are building tax prep software, which is better?

  1. We release software that works, but on April 16th.
  2. We release software before April 15th, that is missing the ability to calculate taxes correctlyWe release software that works, but on April 16th.

Obviously, both are bad, but while #1 will severely impact your annual revenue, #2 will kill your business. In this case, April 15th (Tax Day in the US) is an incredibly important date for our business and needs to be be seriously considered in all product decisions, but it is still less important than building a solution that solves your customers’ problems.

On my teams, we handle this issue with the following product principle:

Dates are important, but they don’t drive our work.

  • We recognize that our customers live in a world that is driven by delivering value by specific dates.
  • These dates are important to us because they represent opportunities for us to add value as well as they can be barriers to adoption.
  • Our value is measured by how well we make our customers’ lives easier. If we meet a date but don’t match the needs of the customer, it is worse than missing the date.

While this doesn’t relieve us from the pressures of date driven needs, it give us a framework to ensure we are consistent in our decision making. Our focus is always on how we can deliver value in a timeframe that makes sense for both our customers and our product team.

Measurement Criteria and Traits for Successful Product Managers

    Discovery : How well does the PO do at uncovering the actual needs of their customers vs. simply taking a list of “wants”. This is really designed to measure their ability to understand the “why” and their ability to translate that into product needs for their scrum team. I also throw prioritization into this bucket.
    Delivery : Does their team actually produce anything of value to their customers and do their customers agree?
    Domain Depth : Are they the experts in their area and can they “speak” as their personas?
    Leadership : I look at their ability to get people to rally around them as well as do people come to them as the “expert”. They have three groups to lead – their team, their customers, and the company (thought leadership)
    Innovation : Are they creative in how they solve problems with the resources they have? Not only are they coming up with new ideas/tech solutions when they have a well-funded, growing product, but how are they getting the most out of the resources they have (this helps when measuring a run-the-business PO)