Adam Bullied has thrown down a “manifesto” to start a conversation on product management - and to try and help drive our community to a common definition or understanding of product management.  And he’s asked for feedback.  Using idea seeding, we’ll see what we can come up with in 30 minutes.

The Philosophy of Product Management

Adam wrote the following:

Product management is the function of serving as a proxy to a defined set of markets (or market segments), in order to be able to ensure appropriate product creation, and ongoing product health and quality for those markets throughout a product’s entire lifecycle, until end of life.

To me, it’s important just to get this out there and then start to gather some feedback from others (yes, readers, I’m talking to you) and then tweak based on the collective.

The Product Management Manifesto

I find that to be generally accurate.  I really like that Adam has stressed the entire life cycle of a product.  But when I read it, I don’t think “that’s what I aspire to do” and I don’t think “that’s what I look for in a product manager.”  And Adam did ask for feedback :).

It is always easier to criticize than to create.  Especially when you look at something and say “it just doesn’t feel right.”  So how do you improve it, when you have no idea how?  You can use brainstorming to come up with new ideas or related insights.  But brainstorming works partly because of the dynamics of the people in the room.  Another approach to invention is idea seeding.  You constrain yourself to a fixed time, and force your brain, under pressure, to come up with ideas.  Pretty much the opposite dynamic of an “anything goes” brainstorming session.

I’ve spent 15 minutes writing so far, quoting Adam, getting an image on my server and getting ready to go.  I’ve got 15 minutes left.  I’ll use 10 of those minutes to write down - sort of stream of conciousness - things about product management that I think either define it, or are important, or frankly, that just come to mind.  Then 5 more minutes to wrap it up and click “publish.”  Maybe these ideas will trigger someone else to chime in and continue to refine.  Maybe even throw out their own 30-minute-improvement-cycle.

Ten Minute Thoughts on Product Management

• Steve Johnson (I think) describes product management as being ‘president of the product.’  That’s exactly right.  It is more than just defining the product, there’s a sense of ownership and responsibility.
• Product management has to have a strategic focus - on markets and problems and value.
• Products, to be great, need to be designed for the people using them, for the tasks they use them for.  You are either intentional or accidental.
• The business of developing products is one that is based on value - problems have costs, opportunities have returns.  ROI is the key to a successful product.  Yes, I want a Tesla, no it is not a good investment.
• Product managers are not passive proxies for markets.  That almost implies that customers define what the product should be.  Customers are always right, but they are rarely product managers.
• A product is never “done”, it just keeps getting better, until the remaining problems are too small to justify solutions, or are better solved with other products.  It’s pareto meets opportunity cost.
• Ongoing product management is about feedback loops.  The more you know, the more you realize you don’t know.  Thanks Nicki!
• There’s more power in active verbs than passive ones.  “Be a proxy” and “ensure stuff happens” don’t have the power, drive, or relevance that I think define a product manager.
• We listen, understand, elicit, analyze, synthesize, extrapolate, interpolate, interview, canvas, survey, study, eat sleep and breathe our markets - and by extension, our customers and their problems.
• We value, prioritize, triage, assess, and measure the value, size, or return of those problems - and ultimately, of solutions to those problems.
• We are the translators - think “universal translator” not Rosetta Stone - active, not passive.

Time’s up.  Drat, was just getting on a role.

Five Minute Philosophy

Spending five minutes to turn the above into an alternate philosophical statement about product management.

Product Managers understand markets and the problems faced in those markets.  Product managers choose the problems to solve, prioritize those problems, and communicate this knowledge to the people who build solutions.  Product managers engage customers and learn from them, continuously improving their products, as long as it is valuable enough.  Product management is the job of being a product manager.

Out of time.

No idea if that’s enough, or even better.  But it is a series of ideas.  Who’s next?  Someone jump on board with your thoughts, either in the comments here, on Adam’s article, or even better - in your own blog.

Jun 14th was the first productcamp in Austin (and the second one anywhere).  It was a great event, and here’s the presentation that I did on how to define the strategic problems that drive our products.

Defining Problems

Here’s the presentation I gave at ProductCampAustin 1, posted on slideshare.  Just click on the forward/back arrows in the center of the bottom of the image, and it will cycle through the presentation - you don’t even have to leave Tyner Blain.

| View | Upload your own

Following Along

In keeping with the “don’t put a lot of words on your slides” tradition, the presentation is probably all but impossible to follow without some notes.  So here are some notes, organized by slide.  The presentation builds on concepts we’ve talked about here over the years, and in the notes below, I’ll link to some of those previous articles to provide more depth (instead of typing out everything I said).

• Slide 1.  There are two key elements to achieving software product success.  Build the right stuff, and build it right.  This presentation is about building the right stuff.
• Slide 2.  Specifically, when we start a project, it is to achieve some business objective.  The challenge is to find the right level of abstraction for that objective.  “Increase shareholder value” is too nebulous, and “Replace a legacy system” is too lacking in context.  Today we will apply a very powerful, but simple technique to help define the business objectives at the right level of detail to be actionable, while providing the right context to validate that we’re doing the right thing. My goal is for everyone to leave here with a new skill that they can immediately apply.
• Slide 3.  Everyone has a different perspective on a software project, and from those vantage points, perceives different elements of the project as the “why, what, and how” of the project.
• Slide 4.  Keeping in mind that people have different perspectives, let’s also look at a modified version of Karl Wiegers’ structured approach to requirements definition.
• Slide 5.  Introducing the Ishikawa diagram.
• Slide 6.  Set up the “deflated tires” problem from the article linked in (slide 5).
• Slide 7.  Showed the discovery process and representation of “real problems” closing out the theme from slides 5 and 6.
• Slide 8.  A real-world project I joined mid-stream for a client.  The project was a “collection of stuff” and no two people would give the same answer for “why are we doing it” and many people unashamedly admitted that they had no idea why.  No idea why!
• Slide 9.  Turns out, here’s what a view of the value for that program really looked like.  The team went from chaos to context.  Suddenly, scope discussions and prioritization decisions had a framework for validation.  There was also an organized way to begin completeness analysis.  Much easier to say “we’re getting this value” than to say “we’re doing these things - did we miss anything?”
• Slide 10.  I facilitated the folks in the room creating an Ishikawa from scratch.  We started with what we thought was the problem statement (provided by John Milburn from the back of the room) - “Traffic in Austin on Fridays is too bad.”  We ended with “John has work-life balance problems”, one of which comes from missing dinner with his wife, which can happen because of a combination of bad traffic and bad planning by John.  We also explored several solution-paths, including increasing the capacity of the roads and of the vehicles.  The ideas clicked for several people in the room.
• Slide 11.  Another real-world example, this one used in planning of a product roadmap for an 18-24 month view of the problems the team was signing up to solve.
• Slide 12.  Special thanks to the sponsors that made our inaugural ProductCampAustin a success!  My prediction for the next one (fall/winter 2008): 250 attendees.  So if you’re the sponsoring type, start planning on how you can help out.

Thanks again to everyone who attended, and special thanks to Tal Boyd of Seilevel, who video taped my whole presentation.  I just haven’t figured out how to split the 400+MB m4v file into something I can upload onto youtube.

Are you a product manager with a technical background? Do you constantly find yourself getting dragged into tactical roles like giving demos or providing feedback on design approaches? Are you getting shut out of strategic conversations about value and objectives and “business drivers”? Or do you think on your feet and perform scintillating feats of business to developer translation (and vice versa)?

Read on for some tips about what to avoid and how to leverage your technical chops effectively.

A Real Concern

Back in February (2008), over the course of a few days, I had a great conversation with a reader (and commenter - thanks again!) that addressed some of the challenges of being a product manager with deep technical skills. In late March of this year, the Silicon Valley Product Group included a topic in their newsletter (and on their blog), Moving From Engineering to Product Management. The author of that article provided some great tips on communication dynamics for a geek-turned-PdM. Today, we’ll pull those ideas together, and add some more, in the form of tips to help product managers who happen to have technical acumen.

First, let me go on record as stating that you do not need to have a technical background to be a great product manager. One of the better ones I’ve worked with had a background in history. MBA-centric, business-savvy, non-technical product managers succeed all over the place. Also - a technical background, even for product managers in high-tech industries, is not a guarantor of success.

Technical Product Manager Salary Data

Last December, we analyzed the salary survey data from Pragmatic Marketing’s annual salary survey of product managers. In that analysis, we found the following:

[Click for larger version]

Conclusion

Technical product managers, at least the more senior ones, are paid less than non-technical product managers - when looking purely at titles. However, product managers with technical skills are generally paid better than product managers without them. One interpretation of the data might be that while technical skills help you earn more in any product management role, the technical product manager role generally earns less - perhaps due to perceived scope of responsibility or impact.

Note that there are two “technical product manager” variables. One is the self-reported level of technical expertise (from non-technical to very-technical), the other is job title (where the choices were product manager, product marketing manager, and technical product manager). The linked survey analysis includes more details, analysis, and perspective.

If we believe that success for product managers will correlate with compensation for those product managers, then we can conclude that a technical background can help you be a more successful product manager (ignore the PMM and TPM data), but only after 10 years of experience. Perhaps it takes time for technically-oriented product managers to absorb the important soft skills.

SVPG Tips

The SVPG article on moving from engineering to product management is a good one. Read it for more details. In short, the author suggests half a dozen tips, all of which are important, to an engineer in a product management role. Also note that the article author also believes that this is a potent combination:

In any case, many of the very best product managers I have ever known have come from engineering, and in this article I’d like to call out what I’ve found to be the main challenges for engineers as they make this move.

Realize that engineers have a big advantage in that they generally have a deep understanding of what’s just now possible. If they can now combine this with a deep knowledge of the user, and develop some new skills, you’ve got the makings of a great product manager and great products can result.

SVPG Tips (paraphrased and shortened here, and links are ours)

1. Realize that you and your users do not think the same way.
   

   “Cooper calls programmers homo-logicus, to distinguish them from actual human users. Because programmers understand how computers work, they have very different expectations than everyone else.”8 Stages of Corporate Usability Awareness

2. Develop empathy for your users (remember, they aren’t engineers.
3. Don’t focus on (your old job of) optimizing developer utilization - focus on optimizing user experience.
4. Develop humility - people won’t always react to your product ideas the way you would like.
5. Refine your argumentation style to deal with unclear situations - there is not always a right answer.
6. Don’t fall into old habits when it comes to working with your engineering team - let them do the engineering.

A Real World Example

Here’s an edited (to protect anonymity, and to focus on having technical skills and product management) version of the exchange I had with our reader.

Product Manager

I really enjoy product management work, and am very strong at building relationships with customers and across teams. But, because I have a strong technical background, and because of where our company is, my responsibilities are shifting much more to what Pragmatic calls a business analyst role — more emphasis on product specification than on product strategy.

I’m trying to build a personal brand. Initially, I resisted the idea of moving back to a more tactical role, but it appears that you cross the line between business analyst and product manager pretty freely. Maybe being known for having strong technical chops is not all bad. My current role is my first as a product manager on the software vendor side, so I could use some perspective.

Scott

Having technical chops has proven to be a huge asset for me, although it comes with some risks. Every software project requires a continuum of thought - from “what is the problem” and “why is it valuable” to “how do we do it.” As product managers, we have to focus on the value and our company strategy. It is the big picture decisions about choosing what problems are worth solving that is the “dog” and it is software design and implementation that is the “tail.”

Making the right strategic decisions requires us to understand both the value of the problem and the cost of the solution - it truly is ROI. It makes more sense to develop a $5m solution to a $10m problem than to spend $99m on a $100m problem. All product managers, have to be able to articulate the importance of the problem - and we can do that with a minimum of technical depth. Where technical depth helps here is in identifying that there are solutions that reduce the size of the problem (think of it as opportunity cost). We can validate effectively.

For example - if companies spend 10% of their revenue on order processing, that is a very large opportunity. And if our target market is companies in a vertical - say medical claim reimbursement, with an characteristic revenue of $100m, it is a $10m problem for each of them. However, with technical chops, we can appreciate quickly that there is likely to be a $100k solution out there already. By decomposing the problem, we can envision stitching together some open-source software to “essentially solve the problem.” This means that while there may be a $10m (per customer) need, there is really only a $100k sustainable solution. The same conclusion might be reached without technical chops by knowing that there’s a vendor who solves a similar problem in the computer industry (perhaps for rebate processing). Either way, we get to vet the size of the problem from the perspective of how easily someone could conceptually solve it. That prevents us from building a $5m solution which will be quickly displaced by someone else.

Technical depth is more easily leveraged when looking at costs and feasibility of solutions. We have to not only validate the importance of the problems we solve, but also validate the feasibility of solution approaches. We have to communicate both with our customers and with our implementation teams. My experience has been that I can leverage my chops both in gaining credibility with the delivery teams and in facilitating much more efficient conversations with those teams. And I can be more confident that they know what I’m asking, and I understand the responses. It has occasionally helped that I can “seed the cloud” in those conversations with “can this type of approach work?” questions.

I’m not saying that I specifically took on the role of design, just pointing out that the conversational ideas have occasionally helped the implementation teams have their own great ideas. And helped me form more effective relationships.

When playing the role of “demo boy” or otherwise on a customer visit, technical depth helps again. There are often “gate keepers” and “influencers” with technical backgrounds who are in the room during RFP/RFQ responses. They occasionally will challenge the technical approach of an application, or express why “their problem is too hard” or “doesn’t match.” When they are right, I can help us reach the same conclusion, and decide if it is time for more features, or different customers. And when they are wrong, I can help them understand too - and leverage them as people who pass along a “their product will work for us” message internally (to their employer).

I mentioned earlier that it is risky. The risk is that I over-emphasize the technical work, or even prioritize it above anything else. Strategic product management is what we have to do - and Pragmatic is right - if we don’t do it, who will? Because we can answer technical questions, there’s a risk that we are continuously asked them. What seems to work for me is to leverage my technical chops only in two ways:
1) to improve my understanding
2) to communicate with technical people

I actively avoid flexing my tech-chops in conversations with non-technical people. The risk is that they start to rely on me.

Technical Product Manager

A lot of your thoughts ring true to my experience, too:

• There have been several times when I have been able to use the technical skills to, as you say, “seed the cloud” with ideas about possible solutions. Sometimes the idea sticks; sometimes there are good reasons why it wouldn’t work. Whatever the outcome, the interchange is fun, and in the end, we all understand better why we’re choosing a particular path from a technical standpoint.
• Good point about the “risk” of showing the technical skills. In times that I have gotten too technical with non-technical people, I find it’s really easy to be pigeonholed as a purely tactical tech guy. Then, when you build a reliance on those technical skills, it’s hard to move beyond that with that person.
• Your examples about sizing problems and solutions are intriguing. You’re putting the emphasis on solutions that provide a sustainable advantage. Competitive barriers to entry are defined by the most cost-effective solution to the problem at hand. Our job as a PdM is to find not only a solution to the market problem, but the most cost-effective solution to the problem. Probably an obvious point, but I hadn’t thought of it quite that way in terms of barriers to entry and sustainable competitive advantage.

My role will be to focus more on execution — to make sure we understand the requirements well, all the way from understanding the market problems down to use cases and wireframes. Priority #1 for the company at this point is to get our platform stabilized, and a big part of that is to be very clear in our requirements. I’ll participate in the broad-strokes prioritization discussions, but my focus now will be more on executing on those priorities, than on prioritizing per se. I’ve heard the term “requirements analyst” applied to what I’m doing.

Once again, THANK YOU for your thoughtful response. We’ll keep up on your blog!

Scott

Thanks again for a great discussion, and for having your folks read Tyner Blain - that still blows me away.

And thanks to you for reading at Tyner Blain - it humbles and excites me every day. Seriously. Thank you.

We know the importance of identifying the use cases that enable our business goals. We also know the value of understanding the actors that will use our products. This article shows how to demonstrate a simple but powerful view that maps the use cases to the actors.

Why Map Use Cases To Actors?

Most use case templates and requirements documents include a place to list the actors for each use case. Very few encourage us to provide a big-picture view. Even users of requirements-management systems are left without an easy way to show this perspective. Can it really be valuable, if it is so often overlooked?

A critical element of defining and managing requirements is assuring completeness of your requirements. The first step to assuring completeness of your requirements is to acknowledge that the requirements represent a structure of decomposition of a problem.

Once you’ve identified the goals of the business (or the problems faced by customers within your market, when taking a multi-customer view), you need to recognize that those goals are achieved by enabling use cases. Each of those use cases is then enabled through the implementation of functional requirements.

Part of defining use cases is defining the actors (a.k.a. users) that perform those use cases. You can (and should) use an actor hierarchy to describe the users. If you fail to define the actors effectively, you risk creating the elastic user anti-pattern. This anti-pattern is what happens when you lose sight of the differences between different user groups. You run the risk of designing a solution that fails to meet the needs of any one group of users, by homogenizing them into a lowest common denominator user. Or worse, cutting user-experience corners, and designing “whatever is easiest” and justifying those decisions by rationalizing a schizophrenic actor who changes characteristics to suit your designs.

Most people defining requirements (product managers and business analysts) will do a good job of defining use cases, and identifying the actors that use them. And most tools and books provide good guidance on how to define an actor, or how to define the actors for a single use case. But so few can give you that big picture.

Requirements Iterative Development

If you have worked the entire lifecycle of a requirements process from problem to solution, you have experienced iterative requirements development. Most requirements processes work top-down (some prototype-driven processes are more “bottom up”). Define the goals. Then define the use cases needed to achieve those goals. Then define the functional requirements…

Hold on.

Don’t let that “agile requirements” vs “waterfall requirements” debate sneak in here. That’s a matter of formality and scale. What we’re talking about, specifically, is iterative development that happens as a result of insight, independent of (or in spite of) the process used. This applies to any process for defining requirements.

You define a set of goals. You may or may not validate that set of goals. You think you are done. You start defining the use cases and mapping them back to the goals. You discover two things. First, some goals are not mapped to any use cases, and second, some use cases are not mapped to any goals. You resolve this. You add and remove goals, and you add and remove use cases. The act of defining the use cases enlightens you about the goals they are intended to support. You are iterating on your goals. Unfortunately, a lot of project managers don’t understand this, and build a schedule around a milestone such as “business requirements approval”. Then when you apply your insights into a revision (iteration) of your goals, during the “use case development phase” the schedule is blown.

You do your change requests, reset expectations, and manage the political fallout of a schedule change. Then after “use case approval”, you move into requirements definition. As you document requirements, you uncover new use cases, or rewrite use cases, or otherwise benefit from the insights you have. And those changes to use cases propagate back up into changes in requirements. Now you’ve really messed up the schedule. The way some people fixate on schedules, you’d think they would rather stick their fingers in their ears and keep the schedule than benefit from improvements now, when they cost 100 times less to fix. Oops. Guess I went on a rant, there.

This is also commonly called “requirements churn” and can be tracked - either in a good way or a bad one. The bad way to track this creates an environment that discourages change (”you better keep the schedule!”). The good way to track this creates an environment of “get it (more) right the first time.”

One way to get it “more right” the first time with your goal definition is to look at the big picture with your use cases. One piece of that is mapping (or tracing) the use cases back to the goals. Another tool is to create a mapping between your use cases and your actors.

Use Case To Actor Mapping

Create a simple grid in a spreadsheet. Each row is a use case, and each column is an actor. In each cell, when the actor is the primary actor for a use case, add the letter “P”.

Primary Actor

The primary actor is the person who is the subject of the use case, performing the verb of the use case on the object. A use case may have multiple actors but has one most important person. The term actor represents the person who takes action - not someone playing a role. Other actors may be involved, either as participants, or as infrequent or secondary performers of the use case.
Some examples:

• Primary Actor: Pilot. Secondary Actors:Flight Crew, Sr. Maintenance Technician
• Primary Actor: Author.
• Primary Actor: Financial Accountant. Secondary Actor: Financial Accounting Manager

Foundation Series: How To Read A Formal Use Case

A simple grid with a handful of use cases and actors would look like the following:

The interesting analysis this allows you to do (and it is more powerful with a larger body of use cases and actors) is to review the big picture. You would ask yourself “who does each use case?” even without this tool. That’s just part of writing the use case. Now you can also ask “what use cases does each actor perform?” And you can easily see to ask questions like “If A03 does that, why can’t A02 do it?”

This big picture analysis, in my experience, will also accelerate the discovery of missing use cases. You should also capture when an actor is a secondary actor in the use case. You will then have a grid that looks like the following:

When asking the comparative questions about UC03, you uncovered another use case.

This tool accelerates those insights, allowing you to make changes “further upstream”, or if your glass is half-empty, correct fewer mistakes later.

Conclusion

Use the use case to actor map to provide a big picture view of how people will interact with your product. This view will improve your understanding of how people use the product, simplify the analysis, and encourage insights earlier in the requirements process.

Adam Bullied wrote a really good article about not losing motivation in the face of challenges. His closing quote spun us off on a philosophical tangent about being “good enough.”

Good Advice

I’ve enjoyed several great conversations with Adam over the past couple years. I thank this blog as the catalyst for introduction to him and other really sharp folks, many of whom generously contribute to the discussion that launch themselves from some of our articles. Thanks to all of you!

Adam’s article wrapped up into three general ideas for me:

1. Good general advice (don’t get discouraged by external events).
2. Good product management advice (focus on the problem).
3. Pragmatic execution advice (be good enough).

On the first point - just go read Adam’s article. You’ll like his writing, and you’ll find a new blog to read regularly (if somehow you aren’t already).

On the second, Adam says the following (the links are ours):

You need to just do a few things really well. In fact, things I’ve already mentioned:

1. Ensure you are solving a problem
2. Align things from top to bottom
3. Execute — quickly and with confidence

This “top-down” stuff I speak of is from the vision / problem identification, to the roadmap, to the requirements, to each release being pushed out the door.

Don’t Get Discouraged, Adam Bullied

Good Enough (For Now)

Adam’s third point, about being good enough, I believe, is an encouragement to make progress, and move the ball forward in the face of adversity.

Perhaps it’s my own character flaw, but my first instinct was to think of his comment out of context. I’ve always believed that “good enough” is the enemy of great. “Good enough” can be interpreted as “do less than you can.” That’s not what I think Adam is saying, although that’s the thought that popped into my head at first. Adam’s point is really a good one - don’t let the fact that you can’t make something perfect today prevent you from making it better today. Tomorrow you can make it better still. Add up enough tomorrows…

Maybe this distinction is why I like the underpinnings of agile (iterative) development. Find the most important thing you can do today and do it. Tomorrow, you will be smarter, having done something already and learned from it. You’re in a position to better understand importance. Use that learning to do the most important thing you can think of - even in the unlikely event that the most important thing you can do is refactor what you just did the day before. Over time, things get better.

Good enough for now means do the best thing you know how to do today. Don’t hesitate because you suspect there is something even better you could do, if you could only think of it.

Maybe this nuance is not communicated well by some proponents of agile development. Many smart people rail against the hyperbole of big-A Agile, and throw the baby out with the bathwater and discard small-a agile.

Present yourself with two possible approaches to deciding where you will live for the next fifty years. The first approach is to decide now (but you have a month to do research and make your decision), and no matter what, you have to live there for fifty years. The second approach is to decide now (and your answer must be given in the morning), but if you decide after a year that you want to live somewhere else, you can move. And every year, you get to re-assess and stay or move.

I like this better than the classic “build a house” analogy, because it represents both the cost of change and the impermanence of decisions in a way that is more aligned with software development. It also allows for some other analogies. If you know that you may decide to move again in a year, you’ll make different investments in your new abode. You may choose to live minimally to reduce the cost of moving again. You may become an expert at moving. And you can easily balance the cost of any particular move with the perceived benefit of making the move. “Not worth it?” stay where you are. As you learn more about where you live (and where you might live), you develop a better appreciation of what is important to you. My guess is that sometime well before the fifty year mark, you would have settled in on the “perfect” home.

Now what are the odds that the perfect home after several iterations of change is the exact same home you would pick with a month of research and no experiences?

Each home is good enough for now, and likely to be better than the last home (after all, you’re smarter each time you move than the time before). And you stop moving when the opportunities to improve fall short of the cost of making changes.

The Cause and Effect diagram is also known as a fish bone diagram, because it resembles the skeleton of a fish. Using a cause and effect diagram can be the most effective way to define the problems that you intend to solve with your product. Get your stakeholders engaged in your program with this compelling visual!

Getting To The Root Of The Problem

In our recent article about writing good problem statements, we pointed out a common mistake people make with problem statements - they confuse the manifestation of a problem with a problem.

Problem manifestation [noun] - an example of a way in which a problem is exhibited, without appreciating the true nature of the problem. Ex: The problem manifestation is that the tires on my car are under-inflated. The problem is that my car is too expensive to maintain.

This distinction is relevant. The cost of operating the car is too high. That is the problem. It happens to be that one reason that the cost is too high is under-inflated tires. If you focus your energy on getting properly inflated tires, it will help (by improving fuel economy a little, and by reducing the frequency of tire replacement) with costs anecdotally. But you will not have solved the problem that costs are too high. Unless you get lucky. Costs can be high because the engine is inefficient or damaged, the aerodynamics of the car are bad, or any of a number of reasons. If you solve the problem by addressing a single manifestation of the problem, without understanding the whole problem, it is only because of luck.

Your Problem Statement is The Problem

In the comments on that article, The Demon points out that it is not always easy to identify the right level of abstraction for your problem. The cause and effect diagram makes it brilliantly simple not only to get to the root of the problem, but to communicate this cause-and-effect hierarchy of problem decomposition.

Cause And Effect Diagram Example

The cause and effect diagram is so visceral that the easiest way to communicate how it works is to show an example. Here’s what the cause and effect diagram would look like for the example problem above, where the cost of operating the car is too high.

[larger image]

The main problem is that the cost of operation is too high. This is the far-right, or fish-head part of the diagram (it is sometimes called a fish bone diagram).

The problem can be decomposed into three separate problems: spending too much on fuel, maintenance, and payments. Each of those problems can be further decomposed. Note that “under-inflated tires” appears twice - once as a cause of low miles per gallon (MPG) and once as an excess maintenance cost.

Alternately, you could recognize that spending too much on fuel could be due to lower fuel economy or excessively high prices. You could then choose to decompose the problem slightly differently:

[larger image]

Either approach results in crystal clarity that under-inflated tires is one root cause of low fuel economy, which is one cause of excessive spending on fuel, which is one cause of excessive operating costs. This visual approach helps significantly when trying to identify the right level of abstraction for expressing the problems in your problem statement.

Problem Abstraction Is A Side Benefit

The really cool part is that the help you get in finding the right level of abstraction for your problem is just icing on the cake. [Ed: No jokes about fish-bone cake. Ick!]

The real benefit comes in communicating and validating the problem decomposition with your stakeholders.

Someone questioned me once on the value of writing passionate requirements. Show one of these to your team, and you’ll get enthusiastic, passionate responses. You’ll get kudos from the business for demonstrating that you understand their needs. You’ll get praise from the implementation team for providing them with context.

Using Visio To Create A Cause And Effect Diagram

Creating a cause and effect diagram in Microsoft Visio is really easy, there’s a built in template, and it’s a good one. Create a new drawing and select the “Cause and Effect Diagram Shapes” template (under “Business Process”):

Visio will create a new drawing with a blank cause and effect diagram set up for you:

Fill in the boxes with the large problems. To get to the next level of detail (such as “Fuel Economy is Too low” in the last example), select the “Primary Cause” shape and drag it onto the diagram. Attach the arrowhead to one of the branches (the fish “ribs”) and start typing. For once, Visio’s default layout is where you want it.

To get a secondary cause shape (such as “Bad Aerodynamics” in the last example), select the “Secondary Cause” shape and drag it onto the diagram. Attach the arrowhead to the “primary cause” arrow you just created.

Conclusion

You already have a good justification for defining problems at the right level of abstraction. Now you know how to easily create a cause and effect diagram to find the right problem definition. As a bonus, communicating with stakeholders just got a lot easier - include this in your BRD.

Today’s article is a harvest of pointers to articles about the focus on problems. An idea farm, so to speak, with really good articles about the importance of solving problems, not just eliciting requirements.

Focus on Problems To Create Great Products

We talked about this in a couple articles:

• Product roadmaps are a plan that shows “what problems will be solved”
• Problem statements, used effectively, are very powerful

And Some great articles on this have also been written recently:

• Jeff Lash tells us to focus on understanding our market problems.
• Amar Rama shows us that understanding problems and requirements is an art and a science.
• Patrick Neeman suggests driving requirements (by understanding problems) instead of gathering requirements
• David Anderson points out that the key to lean is a focus on value (and by inference, problems).

You won’t go wrong by focusing your company, your strategy, and your products on solving valuable problems. Marry those valuable problems with some differentiated and valuable solutions, and your product will dominate your market. Keep your eye on the profitability of the product, and your company will dominate the space.

In the movie Memento, the protagonist has no short term memory, so he tattoos really important ideas on his own body so that he can re-remember them.

Remember to focus on problems!

Is your product successful because you were lucky, or because you were methodical and intentional?

Do you want to build a plan where you are dependent on good fortune, or do you want to make your own “luck?” Both approaches work, but only one makes sense as an intention. Slide 3 of your presentation to a venture capitalist should not say “And then we get lucky!”

Product Success Is Not Easy

Saeed Khan wrote a critique recently, in On Product Management, of an article by Phil Meyers on the Tuned In blog. Phil’s article is an analysis of the pending re-organization at Starbucks, and the one quote that Saeed keyed in on was:

At the end of the day, its simple. Create a product or service that your buyers want to buy and the rest takes care of itself.

Saeed’s point is that it is not that easy. A lot of hard work goes into creating a successful product. And Saeed’s right.

Maybe Phil’s point is that the executive should not worry about the details, and trust in his team to do all the hard work. But he doesn’t really come out and say that, so we can’t really back him up on that front. Let’s give him the benefit of the doubt anyway. There’s another point that Phil makes that is potentially disturbing:

Looking at metrics like average same day sales and products per square foot lead you down some strange paths. Schultz even admitted as much in a letter from the board about a year ago in which he worried about the company ‘losing its core’.

Yes, abandoning your goals to pursue your metrics is bad. But don’t abandon your metrics to pursue your goals - unless all you want to do is get lucky.

You might argue that a company like Animoto got lucky when their product spread virally within Facebook and their user base jumped from 25,000 to 700,000 users. But if you listen to the interview that Amber MacArthur did with co-founder Brad Jefferson, you will realize that it was only when they tweaked their product offering - a response to empirical analysis of product adoption metrics - did their success explode. I would argue that they made their luck by being intentional.

Empirical Processes

When you can perfectly model your business analytically, you can measure the inputs and know (with certainty) the outputs. As a college engineering student, I learned this. Real world processes can never be perfectly modeled analytically. As a professional engineer, I learned this too. Real world processes are empirical. The secret to great engineering is to apply analytics to those empirical processes to create disruptive innovation, and combine it with empirical controls that help you statistically predict the likely outputs. The answer is simply that neither analytics nor empiricism alone can help you achieve greatness.

Business processes are also empirical in nature. Even when you can devise an analytical model for the behavior of an isolated system, you have to acknowledge that no real world system is isolated. You have to expect unexpected inputs into the system. As Saeed points out, you have to apply analyses to make smart decisions when developing your process (or business model, or product). And what Phil appears to discount is that you also need to apply empirical measurements to your process (or business or product) to control the expected results.

Creating Successful Products Intentionally

This article proposes that there are two paths to product success. The first path is simple. Cross your fingers, then get lucky. The second path is harder. Be intentional.

1. Identify your market (and therefore your customers and competition).
2. Identify their problems, and select the ones you will solve.
3. Create a product roadmap (aka a “plan”) to solve those problems.
4. Design and implement solutions to the most valuable problems.
5. Get feedback on your solutions.
6. Incorporate your feedback into your plan (step 3) and repeat.
7. Revisit your market (step 1) and the problems you choose to solve (step 2) and repeat.

Note: Step 7 should occasionally replace step 6, so that you stay focused on your market, and not just an out-of-date snapshot of what used to be important to your customers.

1. Identify Your Market

There are a lot of ways to pick a market to focus on. You can chase demographics - there sure will be a lot of retired people in the US thanks to the baby-boomers. You can go with what you know - years of paying attention to an industry presents ample opportunities to understand the market. You can create an entirely new - blue ocean - market by solving problems people don’t even realize they have until you offer a solution. Choosing a market is the subject of many books, not just an item in a list.

Once you choose a market, you need to segment the market into groups of people who share the same problems and who value solutions to those problems similarly. You can apply market research to improve your market segmentation.

2. Select The Problems You Will Solve

You use elicitation skills to identify the problems that your customers face. And when you have to address multiple market segments, you can prioritize the problems across those market segments.

3. Create a Product Roadmap

Once you’ve prioritized the problems you are going to solve, create a product roadmap. Your product roadmap should show the problems you are solving, and the order in which you will solve them. When you define sequencing, you also must define your approach to scheduling product releases.

4. Design and Implement Solutions

There are two keys to successful execution of the plan you built with your product roadmap. First - use rolling-wave planning to define near-term details and long term vagaries. Second - make sure you have continuous integration as a key component to managing quality throughout the process, instead of checking quality at the end (or even worse - ignoring quality).

5. Get Feedback on Your Solutions

This is half of why agile (when done right) works [Can you believe the discussion over the last year on this article is up to 27 comments?!]. Feedback is not just something you get when sharing a prototype with stakeholders. Feedback is also something you must get as part an incremental release methodology.

You can even measure the ROI of your designs, and incorporate feedback at the design level.

6. Incorporate Feedback Into Your Plan

There’s no point in gathering feedback if your organization and your process are organized to resist changes to the plan. Contrary to what the Standish Group’s CHAOS study has always implied [and we've made this implicit mistake too], release schedules are not the primary measure of project success. In a fantastic article at Dr. Dobb’s Journal, Scott Ambler points out that in his survey results, almost two thirds of professionals find that doing the right thing is more important than meeting a project schedule.

Schedule: 61.3 percent of respondents said that it is more important to deliver a system when it is ready to be shipped than to deliver it on time.

Do the right thing. If the right thing involves changing the schedule, that doesn’t make it wrong. What makes this work is the fact that you are getting feedback early and often. It is a risk mitigation strategy, designed to reduce the possibility that you will create an unsuccessful product. It is not a strategy designed to keep your project on schedule no matter how mis-aligned you are to your market.

7. Revisit What You Are Doing And Why

If step 6 is small-scale course correction, this is large-scale course correction. You may discover that solving a big problem for your customers exposes a new “biggest” problem that wasn’t there before. By revisiting step 2, you can choose to tackle or ignore those newly discovered problems.

You may also discover that by leveraging your investments to date, you dramatically improve the ROI of solving problems in another valuable market segment. This is because even if solutions to those problems have the same value, solutions to those problems now have much lower costs (for you). By revisiting step 1, you give yourself the opportunity to best manage your strategy, your resources, and your plans.

Conclusion

Product Success may have an element of luck, but you should never plan to hit the lottery. Be intentional in what you will do, and a good plan, executed well and adapting to change, will get you there.

A look back at the best from this week in the past.

Foundation Series: Functional Testing of Software

Functional Testing, also referred to as System Testing of software is the practice of testing the completed software to confirm that it meets the requirements defined for the software. A functional test is typically a test of user interactions, but can also involve communication with external systems. We contrast functional testing with unit testing. We also show how functional testing provides different benefits than unit testing.

Requirements Documents - One Man’s Trash…

…Is another man’s treasure. There are many different ways to document requirements when developing software. And there is a proliferation of requirements documents - MRD, PRD, SRS, FRS and design documents. Everyone has a perspective on what each document represents, and each person on the team has a unique perspective on what questions the document answers.

One-Page Marketing Template

Kelly Odell posted a single-sheet marketing plan template, after being frustrated with the massive templates that others have promoted in the past. John Sviokla recently wrote about how the 4-P’s of marketing are changing to the 5-P’s of marketing. Marcus Ting-A-Kee found John’s essay and wrote about it yesterday. Guy Kawasaki suggested that Kelly adapt his template to John’s new approach. Kelly chose to mix the best of both worlds. We add our own spin at the end.

When companies first start off-shoring, they usually send the “low level” implementation work overseas first, to work out the process kinks and manage risk. Over time, your valued, domain-aware developers will perceive a lack of career opportunities with this limited role. Naturally, you will want to consider sending design work offshore too. You can make it work. If you do it wrong, you’re toast.

Different Models for Offshore Development

There are many ways to organize software-creation teams (where creation includes product management, design, development and testing). When developing an organizational design that incorporates elements of off-shoring, there are four primary models for outsourced software creation.

1. No offshore development at all. Occasionally referred to as insourcing, this is the traditional “everyone in one place” model - or at least “everyone in similar time zones.”
2. Low-level outsourcing. The implementation teams (both coding and testing) are located offshore, with design and product management staying local.
3. High-level outsourcing. The focus of this article. Keeping product management “local” but moving design and development responsibilities offshore.
4. Complete technical outsourcing. Everyone except the product manager is offshore.

The models can be most easily compared when the same process is compared in each - just with different locations. Co-location of team members has an impact when comparing face-to-face communication with online / phone / remote communication. But this factor is not a primary one in influencing team-decisions - it is no different than having someone who works from home. The key element in team dynamics is a dramatic shift in timezones.

This timezone shift causes a latency in the communication process, illustrated by the following example:

Imagine the following expensive question and answer session:

• Person A asks person B a question.
• 12 hours later, person B responds with a request for a clarification.
• 12 hours later, Person A clarifies the question.
• 12 hours later, Person B responds with an answer.
• 12 hours later, Person A acknowledges the answer.

When this communication channel happens between an onshore person and an offshore person, it takes 48 hours instead of 48 minutes. The more this happens, the more expensive it is to outsource. The key to making low-level outsourcing work cost effectively is to minimize the impact of this communication latency, while realizing the benefits of lower salaries in the offshore location.

Making Offshore Development Work

This is why proper communication design is the make-or-break element of making collaborative teams work when using an outsourcing model that involves anyone being offshore.

High-Level Outsourcing

Consider the following software development process diagram (from Four Application Development Outsourcing Models):

In this off-shoring process flow diagram, the shaded areas represent the activities that happen offshore. Note that this is the exact same process flow that is used to describe the other outsourcing models. The difference from other models is primarily where resources are located, but also the relevant scope of responsibility. In comparison with low-level outsourcing, the only difference in the process flow is that responsibility for test design and solution design is transitioned to the offshore development team.

Artificial Boundary

This model creates a bit of an artificial boundary between the “interpret requirement” step and the “design solution” and “design tests” steps. This artificial boundary creates a potentially odd dynamic within the team.

To make reading easier, we’ll talk about the development side of the process flow only, but the same ideas apply on the testing side.

This model has one developer interpreting requirements, and a different developer doing the design work. In an insourcing model, those two developers are usually the same person. In large development teams, a common breakout here is architect versus senior designer. The architect (the figure on top) would be responsible for those design considerations that span the enterprise and the senior designer would be responsible for those design considerations that affect a single application. Here’s a good background article by Scott Ambler on approaching enterprise architecture.

Why have an artificial boundary? Because this model is an emergent design.

1. A company starts with low-level outsourcing.
2. The offshore developers complain about a lack of growth opportunities (both career and skill).
3. Executives are not prepared to completely outsource all technical work (risk aversion), or the team is not ready to succeed with that approach.

Splitting the “interpret requirements” task from the “design a solution” task is a compromise. It minimizes the risk associated with providing growth opportunities to offshore team members. That risk is minimized by avoiding the high-latency communication channel (from onshore to offshore) when communicating requirements. Instead, the interpretation of the requirements is done onshore, and that interpretation is communicated.

You can argue that this model is the offspring of a trust issue within the organization. A company can absolutely say “We want growth opportunities for our offshore team members” and at the same time say “We are not ready to relinquish complete technical control.” This is definitely a trust issue, and therefore a perceived risk mitigation strategy. The risk may be very real, or non-existent. In either case, it is emotionally present.

Vague Scope and Role Conflict

If, while reading this, the notion of splitting interpretation from design feels uncomfortable, that’s because it is. For many teams that are evolving their outsourcing model, it feels uncomfortable, but it feels less uncomfortable than releasing complete technical control.

One problem, which I completely grok as a former developer, is that it is almost impossible to interpret requirements without imagining designs. But this model has different people performing the different tasks. So should the interpreter just discard those designs? Presumably the interpreter is more experienced, certainly more knowledgeable about the domain. It would be a shame to discard those design insights.

Robbing Peter to Pay Paul

This approach has clear benefits for the offshore developers who are now presented with growth opportunities. Unfortunately, you run the risk of sucking the fun out of the role of the interpreter - a senior, experienced developer with domain knowledge. While proper requirements interpretation can be fun, it usually is not fun for a developer. Only requirements people will enjoy those nuances, generally.

You risk eliminating a career path and growth opportunities for your onshore resources with this model.

Division of Labor

One approach that keeps the growth opportunities open for your senior onshore technical resources is to have them play multi-product, or architectural roles. This presents an opportunity for these individuals to apply organizational insights across products, finding synergies between applications and driving consistency and consolidation among applications. You essentially split the responsibilities “broad and deep” where the onshore designer is looking across the portfolio and the offshore designer has ownership responsibilities for a single application or scope. This is similar to the division of responsibilities that works well for tackling enterprise product management.

Instead of preventing communication of requirements across the high-latency channel, it minimizes it. The onshore designer acts as the liaison between multiple offshore designers, fielding interpretation questions, and more effectively, preventing them. Developers have a language all their own. Through a shared perspective on common experiences, they can communicate very efficiently - by analogy, symbolically, and via design patterns. These communication opportunities (between like-minded individuals) can have very high information density. For example, one developer can say “MVC pattern” to another, and that serves more effectively to communicate an approach to designing a solution (and a context / interpretation of requirements) far more efficiently than a product manager describing requirements that multiple tools and platforms should expose the same set of capabilities or behaviors [and that is overly short, because I don't feel like typing a comprehensive explanation of the MVC pattern].

Another approach is to silo the developers vertically - having some applications (or modules) following a low-level outsourcing model, and others practicing complete technical outsourcing. Any given team is operating discretely with a clearly defined set of responsibilities. The teams may just be operating differently. Essentially, you’re saying that your “average” is high level outsourcing, even though it is really a mix of two models. This doesn’t really count, since none of your teams are addressing the communication challenges of this model - your company is leapfrogging over it, but choosing to mitigate risk by doing it a little bit at a time.

You can also take the approach of having the onshore designer be responsible for over-arching and high-complexity design issues, with offshore designers owning more straightforward and lower risk design activities.

The best approach for maximizing your team’s effectiveness (and your HR goals) will be overwhelmingly determined by the individuals involved. If you’re in a large company, you probably don’t get to maximize team effectiveness - you are likely to be forced into a particular model. If you’re doing the forcing, recognize that one size does not fit all.

High Latency Communication And Designing

When circling back to the main challenge of offshoring - communication - you need to look at the nature of the communication that is subject to the high-latency of temporal displacement within the team. The key to making this model work is to leverage the efficiency of cross-talk between developers. That means having experienced people on both the offshore and onshore teams who share common design backgrounds (patterns, analogies, examples) and deep domain understanding (reducing the provision and clarification of context across the communication channel).

Design reviews are also very effective at eliminating the impact of this latency on communication. Design reviews typically happen as follows:

1. Designer A spends time creating design based on an interpretation of requirements.
2. Designers A & B get together and review the design in a relatively short meeting (or Designer B reviews a design document). Feedback is delivered in a burst.
3. Designer A spends time updating the design based on feedback from step 2.
4. Return to step 2 as many times as is needed.

There is a big chunk of work involved in incorporating feedback from a design review. This can be folded into the “white space” between communications. In other words, while designer B is sleeping for the night, designer A is making updates. This looks like, but is not the follow-the-sun pattern.

The follow-the-sun pattern is one where someone is always working. I’ve made this work on a project where there were two teams working 12 hour shifts with a 4 hour overlap (and a 4 hour “blackout”). Note - that isn’t sustainable, just anecdotal. I think the linked article is right, commonly, follow-the-sun implementation does not work, for the reasons cited in that article.

What makes this very different is that we are synchronizing the naturally-occurring time lag between design reviews with the geographically-induced time lag in communication.

Conclusion

The strategy for successfully utilizing offshore resources for both implementation and design starts and ends with communication. It also requires attention to your specific people and their career aspirations.

• Utilize design reviews to take advantage of serendipitous time-lags in the communication cycle.
• Assure that your role definitions are clear, and aligned with the aspirations of the people on your team.
• Follow the tips for effective offshore development - this strategy builds on that one, it does not replace it.

Problems are the reason why we create software. We solve problems. For the business. A “Goal” is an acknowledgment that you are going to try and address the problem. One mistake people commonly make is to describe problem manifestations and not problems. Read on to see the difference.

Problem Manifestation

Someone recently forwarded to a mailing list an article about how to define the impetus for requirements. The article was written by someone at a “product management training and consulting” company. Instead of linking to the article, let me just say that it inspired me to write this article, and not because I agree with it. So, the names are removed to protect the well-intentioned.

That article starts with a statement I really agree with, and one I really don’t agree with:

• The Good: “All great products begin with a well defined need.”
• The Bad: “Starting your requirements with a problem statement is a problem.”

The article goes on to describe a problem manifestation*, labels it as a problem, tells us it is bad, and then goes on to propose an alternative. Don’t Build a Stupid Product Roadmap shows a similar phenomenon - someone well intentioned criticized a really horrible product roadmap, and errantly drew the conclusion that product roadmaps are bad. This is the same thing. Problem statements are not bad - in fact, they can be one of the most effective tools for clearly communicating the vision of a product.

*Problem manifestation [noun] - an example of a way in which a problem is exhibited, without appreciating the true nature of the problem. Ex: The problem manifestation is that the tires on my car are under-inflated. The problem is that my car is too expensive to maintain.

This distinction is relevant. The cost of operating the car is too high. That is the problem. It happens to be that one reason that the cost is too high is under-inflated tires. If you focus your energy on getting properly inflated tires, it will help (by improving fuel economy a little, and by reducing the frequency of tire replacement) with costs anecdotally. But you will not have solved the problem that costs are too high. Unless you get lucky. Costs can be high because the engine is inefficient or damaged, the aerodynamics of the car are bad, or any of a number of reasons. If you solve the problem by addressing a single manifestation of the problem, without understanding the whole problem, it is only because of luck.

Abstract Your Problem Correctly

When you elicit a problem from users, it is usually a description of a problem with their procedure, or the design of their product.

• I can’t keep my tires properly inflated.
• It takes too long to find the information I need about the customer who just called me.
• My price catalog is always out of date.

These are examples of how problems manifest, given a particular process or product design. If you start with a problem manifestation like one of these, it will be impossible to avoid design cues in your requirements. And you should always avoid specifying design in your requirements. The article that started us down this path is correct - these are bad things. The solution is not to abandon problem statements. The solution is to abstract them correctly. This is a skill that great product managers have, and all product managers need.

Properly abstracted, the problem manifestations above could be rewritten as problems.

• The cost of operating my car is too high.
• I lose too many customers because their calls for support take too long.
• We are making unprofitable sales (and losing other sales) because we quote incorrect prices to our customers.

These problem statements can be turned into goals, from which the rest of your requirements can be defined. Goals would be in the form “Reduce the cost of operating my car by 20%.”

You can abstract too far. You know you’ve gone too far when the problem statement does not give you any insight into what problem you are solving. Here are the same three examples, abstracted too far.

• I don’t have enough money.
• We don’t have enough revenue.
• We don’t make enough profit.

This abstraction problem is a common one in product management. It has come up in a handful of discussion threads over the last couple of years here, and is a key point in a couple articles too.

• We see incorrect definitions of problem statements.
• We see incorrect definitions of use cases.
• We see business rules and requirements at the wrong level.

Don’t go too far, or your team won’t know what to do. The goal is to understand the problems that affect multiple customers in your market - not just a single company or user. Make sure you abstract far enough, or you won’t actually solve the valuable problems. And without valuable problems to solve, you can’t write valuable requirements.

Conclusion

Problem statements are awesome. They define the scope and vision of what you intend with your software. They provide a framework for measuring the value your customers see from your product. They provide context for prioritization and design decisions.

Problem manifestations are too low level to achieve any of these goals. They are bad.

Don’t abandon your problem manifestation, just ask “why does that matter?” until you reach the proper level of abstraction. Then you’ll know what the real problem is.

A look back at the best from this week in the past.

Foundation Series: Continuous Integration

Continuous Integration

Continuous Integration is the software development and quality process where all team members merge their code and verify it frequently - at least daily. This verification project includes both an automated build process and automated testing. The main benefits of continuous integration come from risk-reduction and cost-reduction.

Ten Essential Practices of Continuous Integration

Martin Fowler has identified the key process elements of making Continuous Integration work. You could even argue that they are the elements that define Continuous Integration (done correctly). We include his list and our thoughts below:

The Agile Dragon

When Alan Cooper and Kent Beck debated the benefits of eXtreme Programming versus Interaction Design, they disagreed on a lot of things. One thing they agreed on is that Agile processes are designed to minimize the impact of changing requirements. Cooper believes that it makes more sense to minimize future change by understanding the requirements better up front. Beck believes that the requirements can not be understood by the team until something is delivered. Beck’s point is that the customer doesn’t understand the requirements until he has something in his hands. We’ve shown how this is both a strength and a weakness for Agile in the real world. In The Hobbit, the dragon Smaug was missing a scale on his belly, that made him vulnerable. Agile processes have a similar weak spot.