Skip to main content

50 Shades of Right in Software Product Development

By January 27, 2015Article

Every product manager strives to build the right thing. In software, there are always a lot of features to build and constraints upon the team, so the goal of the product manager is to do the work to pick the things that deliver the most value to the organization. 

Unfortunately, choosing the right thing is harder than it seems because what’s right for the organization is complex and nuanced. 

Right for some but wrong for others 

Imagine a product manager that interviews his company’s largest customers and gathers data on their needs. He finds the common needs and determines a prioritized list of things to build that best align to their requests. The company starts building the items on this list and ships them with confidence. Yet, six months later they start losing smaller customers – enough small customers that it has an effect.  

So what happened? Big customers often have very specific needs, and those needs are often at odds with the average customer. Worse, these features can detract from the user experience, decreasing the value of the product for the average customer. 

Right for now but wrong for later 

Predicting the future is hard. Sadly, that’s exactly what product people sign up for when taking their job.  We often quote Gretzky’s “skate to where the puck is going,” and that’s precisely what you need to do when leading a product. Tech guru Clayton Christensen provides over 300 pages of material demonstrating the perils of how investing in today-only makes you susceptible to obsolescence. 

Right for engineering but wrong for users 

In the throes of product development we often encounter areas where there are massive trade-offs with implementation. Personally, I think this is where the magic happens in the product development process, but we often make decisions based on how difficult something is to build. Building what you specified may take three to four times more than the time requirement of a different design or implementation. 

Sure, it’s not exact, but we want to get something out there. So we ship it and then it’s not used very much – much less than expected. 

Now we have a problem. We’re unsure if the reason is the implementation (since it’s not what was specified) or that the underlying premise was wrong. The only way to get this answer is to build it the right way, which we know is much more expensive. 

A practical solution

These are just a few examples. There are tons of examples of how “right” can actually be wrong in a different context. So how do you handle these instances? 

First, you need to acknowledge that there’s never the “right” thing to build. Rather, there’s only the “right” thing for a set of given circumstances. The perfect prioritized list is a fantasy that shouldn’t be sought after. 

Of course, some people will note that there are tactical solutions to the aforementioned problems, like building features specific for large customers and simply hiding (or progressively disclosing) them from others. There are always tactical ways to handle some examples, but there will be examples that don’t have such a simple answer. 

The keys to adequately addressing this are transparency and alignment. 

It’s important when communicating any prioritized list of items to explain the rationale. In the first example, this product manager has a prioritized list of items specifically for large customers.

Everyone in the organization should understand this bias and sign off on it. In the last example, we made a decision based on cost, not user needs. Communicating “why” is critical to helping the organization understand the prioritization and prepare for alignment. 

Now that everyone is fully aware of the rationale, you need to ensure that this prioritized list is aligned with the company goals. Going back to our first example, we should ask:

  • Is the rest of the company prepared to support the needs of larger customers?
  • Will we support their scale operationally?
  • Do we have the right support and consulting staff to handle their requests? 

Regardless of the priorities, having an entire organization aligned around a plan and strategy will deliver the best results. 

There is no “right” only balance

Finding the most perfect “right” thing to build is a unicorn. More important than finding the “right” thing is to create a balanced portfolio of investments that accommodates competing priorities and situations. This is particularly difficult when you consider the timing of things. Most companies have annual plans (budgeting, staffing, etc.). Sure, there are multi-year plans, but often they are weakly scrutinized and mostly guesswork. 

Contrast that against product development, which is a multi-year investment.  It takes months to build some features and more months for customers to fully adopt them. There are things you start building in June that will not affect the current year’s plan at all. 

In order to accommodate product timing, you should create balanced prioritizations. In our previous examples, it may mean spending 70 percent of your engineering capacity on the big customer list while reserving 30 percent for general features benefiting all customers.

So instead of striving to build the “right” things, good products managers should strive for balance. And once the priorities are set, check back in on your decisions and measure their effectiveness to continue improving the process. 

Todd Olson is the CEO and co-founder of Pendo. Prior to Pendo, Todd served as vice president of products at Rally Software Development. Todd joined Rally via the acquisition of 6th Sense where he was president and CTO. Todd has also held leadership positions at Borland and TogetherSoft. Todd is a frequent speaker on agile software development, product management, and entrepreneurship. Todd can be reached at todd@pendo.io or via twitter at @pendoio and @tolson.