The regrettable features you have to do

Red Skelton painting of a sad clown

Sometimes as a product manager you get a feature request that’s fun and challenging and moves your company forward. Then there’s requests that just make you feel like a sad clown: stuff that doesn’t fit your plan at all. It’s hard work to ignore the nay-sayers and make a new thing. The product team and engineering have worked together to create a different and better approach to a class of problems… Congratulations! But there’s features you may need to build even though you don’t want to.

Compromise between your product differentiation and market fit comes in three flavors:

  1. legitimate needs that you hadn’t recognized or accounted for
  2. a culture of design that you’re hoping to change
  3. technology requirements that you don’t address

A legit need might be regulatory compliance that your design doesn’t account for well, or a use case where you were too optimistic about your solution’s fit. This feature request is legitimate, and the regrettable part is wholly on you and your team. You have to find a way to solve it or accept a limit on who you can sell to. That story is beyond the scope of this post.

But design culture… here you’re trying to change behavior. You think your product has a better answer, and you need customers to take a leap of faith. If you have an interesting idea you’ll probably be able to find early adopters, but these customer have a lot on the line. It’s only natural that they want the safety of familiarity or a backup plan, and you may need to offer a bridge feature.

Lastly, technology design choices are anything but simple: some design domains just aren’t good fits, or aren’t within your company’s scope. Another source of compromise is design fashion. Ideas cycle in and out of fashion as the memory of failure fades. This can mean surges of industry excitement about concepts that you don’t personally agree with. Always begin with questioning your own assumptions, because conditions do change. Sometimes the idea that fizzled last time or the time before succeeds in the next iteration.

No matter what you think of design fashion, it’s not likely that you’ll be able to refuse to play the game. Your company is on the competitive field, and you have to have a response, or else your response is going to be whatever your sales people think of. So, research the problem space and ask what has changed. If there is new opportunity and you can capitalize on it, this isn’t a regrettable feature. That story is also beyond the scope of this post. But if you do your research and you don’t see how this time is any different, then you need to find an answer which minimizes investment while maximizing information return.

That is the same regrettable feature answer as when the idea in question is not new fashion at all, but just not a good fit: a concept that your company doesn’t and/or won’t play in. If it’s not a good fit, then you shouldn’t build it, but you can’t ignore everything that isn’t a good fit.

So, regrettable features: bridges from old patterns to new, fashionable experiments, and requirements you don’t want to or can’t satisfy. What can be done by partnering, adding content, or re-marketing what you already have?

Partnership can take a couple of flavors:  total outsource of the problem to a chosen vendor, or meeting the community at an interface. The total outsource is least effort on your part, but it only works if the partner is a de facto winner in the space. You don’t make success by stacking failures together. So if that obvious winner hasn’t taken all, you need to make a clear interface that treats them all the same. Set your terms, define your boundaries, pick a couple of partners to go to market with, and see what happens. You’ve got a feature, but it’s stripped to the minimum.

Adding content is another option for vendors who have a strong enough boundary between platform and content. If you have a community of customers, field engineers, and pro service partners building content, then you can solve problems without engineering and support contracts. This approach arguably has a limited shelf life because some customers will push back on the unsupported nature of roll-your-own or second party content. That point can be far in the future though, and you’ll certainly get some real world data about what customers want.

Re-marketing is the toughest option, saved for last; only the very lucky vendors can shake the puzzle box and get a better picture. But if you can package your components differently to resolve a problem, it’s a lot faster to do that work with legal and sales ops now instead of after engineering is done.


%d bloggers like this: