This is the third post in a series I recently started on software development and the role of the Product Manager.  If you haven’t already done so, it might be a good idea to read Part 1 (Overview) and Part 2 (How to ensure that product requirements are informed by user needs) before your read on.  This post continues the discussion on Product Requirements and the different sources that should feed into requirements.

In Part 2 of this series I discussed the role of user needs in product requirements, and in this article I’d like to talk about the role of business needs and technology needs, and making sure that the right balance is struck when incorporating these (often loud, often conflicting) voices in the organization into what gets built.  So, let’s dive in…

Business needs

When I was at eBay, we often heard the mantra from our executive team, “If you fix the user experience, you fix the business.”  Lovely words, but when it comes time to decide what to build, “Fix the business” usually comes first.  This is, of course, not a bad thing, but unfortunately the best user experience often means taking revenue-generating features out of the product.  Would we have banner ads if UX really was king?  Don’t think so…

Still, you have to make money.  That is, after all, the point of the business.  The trick is to understand the difference between good revenue streams and bad revenue streams, and opt for the good ones as much as possible.  A good case study on this is eBay’s interesting approach to photos in product listings on the site.  eBay started charging users to add photos to their  listings pretty much from the very beginning.  This was back in 1995, and in those days storage wasn’t dirt cheap, so it was a natural thing to do.

As the years went by, and more and more photo sharing services popped up that allows users to upload and stores pictures for free, this approach became increasingly frustrating for users.  The other side of the story is that it’s actually in eBay’s best interest for users to upload photos of their items — items with photos convert way better than those without photos.

Still, it took many months to convince the executive team to make it free for users to upload photos of their items.  This is an example of a bad revenue stream — it brings in money, but to the detriment of users and the overall success of the business.  When it comes to adding revenue streams to your product, the important question should always be: are you doing this so people will buy it, or are you doing this so people will want to use it and be willing to pay for it?

In a recent interview on Microsoft and tablets, Steve Ballmer said the following:

And so we are working with [our] partners, not just to deliver something, but to deliver products that people really want to go buy.

And in that lies the core of what’s wrong with Microsoft — the difference between making products users want to buy vs. making products they want to use.  When you make products people want to use, charging for the value it brings (i.e., looking for good revenue streams), becomes so much easier.  Approaching it from the more negative side, I guess you could also say it like this:

Technology needs

One of the dangers of product roadmaps and the PM’s role is that back-end maintenance and optimization can start to take a back seat.  This is a huge mistake, best explained through the metaphor of technical debt. In Steve McConnel’s great post on this topic, he defines technical debt as follows:

The first kind of technical debt is the kind that is incurred unintentionally. For example, a design approach just turns out to be error-prone or a junior programmer just writes bad code. This technical debt is the non-strategic result of doing a poor job.

The second kind of technical debt is the kind that is incurred intentionally. This commonly occurs when an organization makes a conscious decision to optimize for the present rather than for the future. “If we don’t get this release done on time, there won’t be a next release” is a common refrain””and often a compelling one.

He goes on to explain why this can become a problem:

If the debt grows large enough, eventually the company will spend more on servicing its debt than it invests in increasing the value of its other assets. A common example is a legacy code base in which so much work goes into keeping a production system running (i.e., “servicing the debt”) that there is little time left over to add new capabilities to the system. With financial debt, analysts talk about the “debt ratio,” which is equal to total debt divided by total assets. Higher debt ratios are seen as more risky, which seems true for technical debt, too.

Technical debt isn’t always wrong — quick hacks to get a product out the door is often the right choice.  But as with most debt, it’s important to start paying it off in small chunks as soon as it’s incurred, before you get into too much trouble.  If you’re interested in this topic, also read Andrew Chen’s great post called Product Design debt vs. Technical Debt.

Striking the right balance

Now that we’ve discussed user needs, business needs, and technology needs, the obvious question is: how do you decide what to build now vs. later vs. not at all?

For that, the right answer is unfortunately, in my experience, the traditional cop-out answer: it depends. It depends mainly on the following factors (in no particular order):

• The level of user engagement and involvement.  If users are screaming for a particular feature, or if there are rumblings around “why haven’t you done anything for us recently?”, it could be a good time to up the level of customer needs you meet.
• The stage of the product in its lifecycle. If the product is just at the beginning, customer needs will most likely come first.  As the product matures, technology and business needs become more important and should start taking precedence.
• The financial state of the business.  If there are ways to add good revenue streams, those opportunities should always be taken.

Depending on where the business is on each of these 3 factors, the different inputs might be weighted differently. If the product is going through a growth spurt with lots of buzz, more attention could be placed on user needs. If the product is mature and making good money, technical needs might get more weight.

Exactly how this is balanced in each version/release of the product has no clear answer, and it’s where the art of product management comes in. But one thing is for sure — none of these needs can be ignored for any extended period of time. Take too long to pay down technical debt, and your platform will become bloated and unable to scale. Focus on making money too much, and users will fall out of love with your product.

Successful products have clear product management leaders who are able to take all the different requirements inputs, place it into context with other external and internal pressures, limits, and opportunities, and design a product vision and a (flexible) product roadmap that ultimately increases product/market fit (which I mentioned briefly in Part 2 of this series).

But what do product requirements look like, and what is the Product Manager’s role in that process?  That will be the topic of the next post…