now, once we do have the ‘big view’ — just enough to be sure we’re solving the right problem, have a vision and business case, market understanding etc. — i want to get back to a key point in Scott’s article case around ‘concise requirements’.

for me in working with agile teams, a key is having those acceptance criteria. so yea, we want to be concise, but also unambiguous (clear) with each of these small, tamped down requirements. the acceptance criteria help us do that.

~ ellen

I wrote about the issue of problem chains a few years ago. We will never comprehensively address a core need of human beings (e.g. happiness).

What we do as product managers is identify problems further down the chain that are obstacles to satisfaction of core needs. We strive to find problems that are as high up the chain as possible, but only insofar as we can confidently promise to solve them. Otherwise, all of our problem statements and requirements would focus on health, sex, safety, and social acceptance.

I’ve been thinking about this for a couple days, and I think at the end of the day, 3 is the problem – companies are spending “any money at all” to understand their customers. But that means the real problem is that our customers need to understand their customers. Some of our potential customers will have no solution in place for that problem. Others will have solutions in place (home grown or purchased). We have competition that solves this problem. Our customers have to choose how they want to address this problem – our solution, someone else’s, or their own (or continue to have no solution).

The cost of our solution is probably relevant to our customers and prospects when making purchasing decisions, as would be other elements/attributes of our solution and other solutions. As part of our market analysis, we should estimate the number of potential customers at given price points. Included in developing that estimate is an understanding of current costs and associated potential savings (at each price point). Or a continuous function of “value vs. price” if discrete points don’t make sense. Depending on how we want to position and penetrate the market, we can pick one or more price points versus that model.

From a business standpoint, we should have a target profitability model – at price point X, we can spend Y to develop the solution, and Z as ‘cost of sales.’ I’m oversimplifying, but basically, there’s an amount we can spend to create, maintain, and sell our product and meet our corporate profitability objectives. We may even choose to operate at a loss, for other reasons (like penetrating the market).

From that point, we should be balancing our sales / customer sat / etc versus the model, and our costs versus the model. Any variance analysis (didn’t sell as much as we thought it would, cost much less than we thought, etc) should drive both an assessment of the model’s accuracy and of our performance in defining the right product, as well as our execution in creating it.

Is there a better strategic framework for driving this analysis than saying the requirements is “25% cost reduction for our customers…”? Yeah, probably. We want to say “provide a solution that has X cost for our customers, while yielding Y profit for us.”

@Scott: In comment #11, I agree with this, but I also agree with Roger. the 10% is the impact, not the problem. On top of that though, I agree it is very important to understand and communicate the impact for all the reasons you stated in comment #14.

A few observations.

First, there is no disagreement over the idea that we need to quantify the the extent of the problem and the extent to which we are promising to solve it. Stating least stringent conditions is a core part of expressing requirements.

Second, I am skeptical that we would want to take on the requirement “reduce the cost [for our customers] of understanding their customers by 25%”. In our market research and requirements elicitation, we’d want to probe why it costs too much to understand customers. Those reasons might be the problems we’d choose to solve.

Third, there are subtle semantic implications to your quantifying of the problem and the requirement. Which is really the problem:

1. Spending 10% of revenue.
2. Spending more than 7.5% of revenue (knowing that the actual amount is 10%).
3. Spending revenue (no matter what the amount, but we want to reduce it to the extent feasible).

You seem to be stating that 1 is the problem, and the inverse of 2 is the requirement. I contend that all three are problems, but that 2 is the problem we are choosing to solve, and the inverse of 2 is the requirement.

On “… are use case steps and user interface specifications inherently design, or … terminology contraditory?”, yes, you can do it that way. I was shocked to find that requirements are theory driven. I wasn’t as shocked to find that integration applications negotiate away meaning, hence the terminology problem. Neither of these two things works in a long-term market adoption situation. Going directly to Saas and dying young will let you engage in those practices.

On problem, the customer spends time solving the problem, aka engaging in some ritual, but the programmer who doesn’t engage in the problem as a user will solve the problem in their own way, not in the way the user would solve the problem. So much for listening to the customer, or eliciting requirements from the user. Fundamentally, we need to preserve the user’s meanings and rituals.

Let me try writing it another way – I suspect we agree, and are just ‘talking past each other’.

There’s a trend among [my target customers in my target market], that they are spending ~10% of their revenue on understanding their relationships with their customers and prospects. My target customers have an abstract goal of “be more profitable.” To your point, we aren’t signing up to solve the abstract “be more profitable” problem, because we have a strategic focus as a company on providing solutions “in the CRM space.”

We’ve identified (because we know the domain) that companies spending 10% of revenue on understanding relationships [solving some problem of theirs] have an opportunity to spend much less than 10%.

1. Our customer’s problem was “we don’t understand [their] customers.”
2. Our customer’s requirement was “develop an ongoing understanding of [their] customers.”
3. They chose a solution that cost them 10% of revenue, creating a new problem:
4. Our customer’s problem (now) is “understanding our customers is too expensive.”
5. Our problem is “the cost of understanding their customers is too high for our customers.” Note that our problem is their problem.
6. We do an analysis of “how much of that problem should we solve?”, and decide (strategically) to solve 25% of it. That’s a solution we could successfully take to market. Or so we believe.
7. Our requirement is “reduce the cost [for our customers] of understanding their customers, by 25%.”

So we almost entirely agree. We’re only differing in that I find it to be important to call out the “how much” element – because that is (1) key to our market viability, because it defines how much our product would be worth to our customers, and (2) it defines clearly when we are “done” and ready to go to market.

You give as an example of a problem statement:

“[T]arget customers in target market] are spending 10% of revenue on [solving some problem of theirs].”

I guess you could characterize the “[problem of theirs]” part as the the primary problem and the effect on revenue as a higher-level problem (a financial context) that results from it.

We have to choose which level of problem we are going to solve. I doubt we’d want to be accountable for solving the higher-level problem, as some of its causes are likely outside of our control.

From your problem statement, it’s not clear what level of problem you want to solve. But then your requirement suggests that you have chosen to solve the higher-level revenue problem, not the primary problem that causes it.

Whatever level of problem we choose to solve, in my opinion the requirement is nothing more than the logical inverse of it. Thus, if you choose “spending 10% or more of revenue” as the problem, then “spending less than 10% of revenue” is the requirement. Surely the problem has been solved or avoided if the condition that you stated as the problem no longer exists.