08
Dec 14

Reversing Cognitive Decline – Podcast Episode #4

As a product manager, one of your most precious resources is your “cognitive storage tank.” It’s like a real fuel tank – when it’s exhausted, your cognitive abilities stop working well. And when that happens, it means you can’t be as innovative, you can’t be as creative, and your decisions get worse. To improve our effectiveness as product managers, one key step is managing the cognitive storage tank.

In this podcast I describe some techniques and tools for eliminating wasteful leaks from your storage tank – I hope the ideas will be helpful for you as you improve your effectiveness as a product manager.

Let me know in the comments on the show notes if you have additional thoughts or questions.

Show Notes

If you like this podcast, please subscribe via iTunes (you can search for “responsibility authority” to find the listing) or your favorite subscription method via this feed. And please consider rating and reviewing the podcast on iTunes. The feedback is very helpful for me.


16
Oct 13

Use A List Of Major Impact Areas To Think Through New Features

I often use a list of product “Impact Areas” to assess the impact of a new feature on the rest of the product.

As I’m developing a requirement, I go through the list of impact areas and note down whether this feature requires a change in that area. If not, I mark it as “N/A.” If there is an impact, I note it down. When I was managing Accept360, some of the impact areas were:

  • Table views and filters. (We had user-definable filters for finding entities, so if there was a new property, you’d have to make sure the filters supported it and the result list could display it in a useful way)
  • The release or sprint backlog. The feature might need a new column, or a new business rule for calculating a column value
  • History log entries
  • Default values or settings
  • Notifications required for this feature
  • The terminology and lexicon for the feature
  • Are there best practices for using the new feature? What are they?
  • Import or export 
  • Does this feature make other features obsolete?

In Accept360, I created a page in the requirement template with the Impact Area list. It was easy to go through the list and enter the notes. Today, using Confluence, I typically use a child page to capture the impact areas.

It’s sometimes difficult to make yourself go through this list, but particularly for bigger features, it’s a valuable exercise.


25
Sep 13

Ten Tactics To Do The Impossible

Routes de l’impossible Pérou (CC 2.0 license, some rights reserved, by Attraction Voyages Pérou & Bolivie)

It’s easy to be a product manager if your backlog only contains features your team has the capacity to deliver. But what if you have five large must-have features but your team only has capacity to do one or two. This is where PM becomes an art, rather than a science. This happened to me recently. During a sales engagement for what would have been our largest or second largest ever deal (very big!), the prospect told us we were losing the deal because of five specific features – all large, all valuable, all useful to many of our other customers, that were already all in our backlog, but uncommitted. They said we’d need those five features in order to win. We had capacity to do one, maybe two, in the short term. How could we handle this situation?

There were ten (OK, eleven) tactics that we used to prepare a response.

  1. Make sure you understand what the customer is asking for, because until you do enough requirement gathering at least to get realistic usage scenarios from the customer, what you think they mean might be quite different from what they actually mean.
  2. Look for synergies between the features that allow you to do two for the price of one (or one and a half).
  3. You can commit to delivering one of the features in the near term and the others later. This sometimes is good enough for them to make the commitment to buy from you, especially if they expect to get a lot of value from your product overall.
  4. You can commit to making the features over time and in the meantime get the customer into the product – start the onboarding process – with the expectation that their priorities will change – their original requests will end up not as important as they originally thought.
  5. Get the customer to fund work on one or more of the features – this can work if you have additional resources that can be added simply by buying them.
  6. Get another customer as a sponsor for one or more of the features, to enable you to put more resources on it.
  7. Investigate whether delivering partial versions of one or two of features will get you enough credit to win the deal.
  8. Convince the customer that one of more of the features is actually NOT important to their success, usually due to some other capability in the product.
  9. Sometimes you have to tell the customer that you will never commit to, or even consider implementing, one or more of the requested features – if it just doesn’t make sense for your product and value proposition.
  10. Consider if there is a staging of the features that makes sense, where you wouldn’t want to deliver the later one until the earlier one was done anyway.
  11. Create a Services engagement to do some of the new features manually, rather than automating them. This can especially help if a feature is really part of a change management process and you are confident that the desired feature will not really be important once the customers starts using your product.

In this case, I was confident that a combination of a few of these – in particular 3, 6, 7, and 11 would have enabled us to win the deal, and we made good progress with the prospect on making that case.

Unfortunately, my company executives decided to do none of these, and to double-down on another product initiative (not mine!) that they felt was going to result in much more business. They were wrong, sadly. (We sold $0 of that product.) And the customer ended up buying from our competitor.

The postscript to this story was that the customer was not satisfied with the competitor and later came back to us to see if we’d addressed any of their issues (which of course remained important to them and to our other customers). But we’d continued the investment in the other product, and did not address any of their backlog, so we ended up losing a multi-million dollar deal twice. 

There are lessons learned here, in addition to the tactics. I’ll talk about those in a future post, you can be sure.