If you want to be a bad product manager, gather requirements. How else will you know about what to put in to the product if you don’t ask others? Interview current customers, ask them what their requirements are, and make sure to capture them. That’s what being “customer-focused” is all about, after all — responding to any customer request. Make sure to gather requirements from internal stakeholders too. Get a list of features from customer support, marketing, sales, and senior executives. If you just gather all of the requirements from all of the right people, you’re bound to have a successful product — right?
If you want to be a good product manager, understand unmet needs and use that insight to drive requirements. A product manager who just “gathers requirements” is doing nothing more than taking orders or documenting requests. Good product managers add value to their product by understanding the problems and needs behind requests.
Requirements gathering is an activity often thought to be the cornerstone of any project. The mentality comes from traditional information technology projects, where “the Customer” who was funding the project appeared to know exactly what was needed, and an “analyst” would document the requirements. Successfully gather the requirements, document them, and get sign-off, and the end product will be guaranteed to meet the customer’s needs — or so the theory went.
Of course, this theory fails because “customers” usually do not know exactly what they want and can rarely understand or articulate what they really need. They may have an accurate picture of some of the obvious needs, though often they do not recognize the underlying problems nor are they in a position to come up with the optimal solution. For example, a customer may request a small change in a 10-step process, though someone in a position to better analyze the problem may be able to figure out a way to reduce it to 3 steps — or eliminate the process altogether.
Additionally, gathering requirements from various parties will inevitably lead to conflicting requirements. One type of end user wants a simple Google-like interface on the home page, while another wants lots advanced search features; one internal department wants to use the home page promote what’s new on the product, while another wants to market other solutions which the company offers. These requirements are impossible to all fulfill simultaneously, so the act of gathering them in and of itself has left you no better off than you were before. Additionally, by asking for “requirements” from each group, you have set up each group for disappointment when they eventually realize that their “requirements” were not and can never be met.
A product manager — or anyone — who is just focused on “gathering requirements” misses the greater value that their role can bring. Simply put, there is no value in a product manager who just gathers requirements. The product manager must add value through insight and understanding, by making decisions about priorities and focus. Those who gather requirements just document; the product manager must
- Set the vision for the product: Which customers and internal stakeholders are important to the product’s success?
- Prioritize the different customer needs: When needs conflict, whose are more important?
- Determine which needs will and will not be fulfilled: Does this fit with the vision and strategy for the product?
Good product managers do not just gather requirements — they understand unmet needs, existing problems, and opportunities for improvement, and they then use that information to determine the requirements for the product.
Translations available:
Jeff:
Your observation was right on….I use the terms “Voice of the Customer” (unmet, but expressed/known customer needs often contained in requirements documents) and “Heart of the Customer” (unmet, and unexpressed customer needs).
When a product development process can identify and address the latter, sustained strategic differentiastion can occur. When it focuses on the former, what we typically get is only incrementalism….
Nice take! I extended it a bit on my blog but appreciate the honesty.
Hi Jeff,
I agree – was it Henry Ford that said if all I did was to listen to my customers all I would have done was to build a faster horse. Free thinking and innovation has to be the name of the game.
Derek
What you are really doing is a mental bases analysis. Think strategically and you shall live long and prosper. Strategically also means you need to shun making the product an answer to “life and everything”.
Cheers!
http://randomjunkyramblings.blogspot.com/2008/05/good-product-management-and-delegation.html
You have to understand the customer problem first and then figure out how to solve it in the best possible way. Once you do this, then check with the customer if you have identified the real problem, check if the proposed solution will work and then gather requirements to ensure that the proposed solution will work.
I have found that customers often propose solutions without stating the problem and it is our job to figure out the underlying problem. Otherwise you could end up implementing their solution and it could very well be the wrong solution.
But requirements gathering should be part of a product manager’s job.
Setting the vision is really important since most of us are launching products that will evolve over time. The framework we develop needs to accommodate growth without necessitating a complete redesign every time a new feature is added.
I think one of the most painful processes is getting stake holders to articulate what and why, as opposed to how (to your point about process reengineering).
Finally, since most PM’s are subject to executive override, we can’t get too upset if in practice our vision for the product is tweaked to satisfy corporate/departmental agendas.
Requirements capture is one way to learn from the customer, but it only one way. Learning is important, because the more you learn the better able you will be to create something intuitive. Writing something intuitive is important, because if you don’t, then you end up teaching the user, or worse, the market.
On SoftwareCEO, there are posters that say that if they have to teach the market, they’d rather not begin.
As far as vision goes, if you are working with the technology adoption lifecycle, those bowling ally custom applications gigs are there not to create your vision, but the client’s visualization. The client’s visualization will easily become a successful vertical product, and beyond.
Learning from the customer affects the bottom line.
If you are in a recession in the late market, move towards mass customization.
All to often requirements gathering is a process of aggregation, of mass. Using an application is always an individual act. The effort needed to get what you want from an application is inversely proportional to the aggregation that shows up in the requirements.
Requirements isn’t just about what. It is also about who. That who is cultural. That who is meaning.
We were taught to ignore the who beyond roles. As a consequence we destroy meaning, we make use harder at the model, not just the interface, and we allocate hidden costs to the user’s enterprise.
Pay attention to cultures, particularly functional cultures when gathering requirements. This will help you as you get ready to focus on the individual in a mass customization effort.
I have a great story that I was once told about a very cranky customer. Their expectations were not met; they were extremely dissatisfied with the product and had a laundry list of features that simply MUST BE in the next product release (already in development). However, rather than simply respond to the feature requests, derail the current development plan and continue down a very slippery slope, the company sent an analyst to them, onsite for a week. Based on the analyst’s observations, they were able to guide the customer and demonstrate that 80% of what they wanted in the product was already there. Today, they are a 100% happy customer with not a single one of their MUST HAVE features going into the next release of the product.
I think Chad’s story is rather compelling. Perhaps — as part of the product management process — something could be done about adequately explaining the product. How many customers are upset because they do not know how to optimize the product? And are there innovative ways to get the word out?
Chad,
In your case, I would question the discoverability of your product features if you had to send an analyst before your customer could discover that 80% of what they wanted was already n the product. Neither is this cheap to do nor is it scalable.
Unless this customer was using your product in a very unique way that no one else would, take this as a great feedback – what could you do to make the features more discoverable.
This is one of the biggest challenges that product managers/designers face as the product grows – it is something I have struggled with as well, with no good answers. Look at MS Office – I still use the same features as in Office 97 – what happens when your customer base falls into this mode as your product gets really big.
I would love to hear from others who have figured out how to do this best, because I could learn some things here.
You might be looking at your product from the standpoint of a sample of a normal distribution. You gather requirements from ALL the users and average them out. You could look at your product from the standpoint of Poisson distributions instead of segments. This would allow you to tune the use to these populations. It would also enable you to fill the needs of a single population before you move on to fill the nees of another population.
It would prevent you from delivering functionality of an average fit. But, that means that you would have to extend the existing functionality to fit the population, instead of insisting that the population fit the existing functionality.
Use is based on meaning. Averaged functionality negates meaning at the edges and sometimes at the core.
Once you can map individual populations to your functionality, you can deliver the desired functionality with a veiw created specifically for that population. You may need a population specific model as well.
An example of what you are looking for is MS Word. Back when WordPerfect was the word processor of choice for the legal profession, MS provided a function that duplicated the WordPerfect keyboard assignments. This allowed legal secretaries that had to type 200+ words per minute to use MS Word without learning anything new.
WordPerfect changed those keyboard assignments often without regard to the learning load that they created.
At any rate, it worked, because the legal secretaries moved to MS Word.
When your functionality is wide, there will be communities of users that use the core and a few other feautures, and other communities that use the core and a different collection of other features.
It may not require that you change your interface, but you might want to write different manuals for different populations.
Consider the now-famous collaborative filtering navigation mechanism for book recommendations on Amazon.com. Maryam Mohit, responsible for the online customer experience at Amazon, explains in an interview with Mark Hurst that the idea for that feature was inspired by users, but didn’t come directly from their comments:
“It’s a combination of listening really hard to customers, and innovating on their behalf. For example, quite awhile ago we developed the “similarities†feature – the one that says “people who bought this also bought that.†In focus groups, no customer ever specifically requested that feature. But if you listened to customers talk about how they buy things, they’d say, my friend bought this, and I like what they like. In other words, they get recommendations from people they trust. There was a cognitive leap, based on those comments, to realizing that we could create something like that based on the data we had. That’s an example where there was a need expressed by customers, but the innovation was taking that general need and making the leap to a technology that meets that need in a new way.â€
I like the “innovating on their behalf” comment.
I can see the benefits you mentioned applied more in Web 2.0 portals, when the customers are the members of the portal, and when each one of them has different views and needs of the product. So the product manager in this case should be able to address requirements that fits most of the audience and I believe this is not an easy task!
When you define “requirements that fits most of the audience,” what you end up with is every customer having to compensate for the needs they have that are not average. Try banning Access and Excel or insisting that interfaces for such not be provided. Then, you will see that the satisfaction with your averaged functionality is a lot lower than you’ve anticipated.
When you look at pricing and other strategy elements, one strategy that appears again and again is that of de-averaging. You can charge different populations different prices. You can do one-to-one relationship marketing, which differentiates specific populations in terms of retentioin efforts.
If you are a vendor in the horizontal (IT) market, de-averaging doesn’t make sense. But, once you are in the late market and face competition on price, de-averaging is essential, as is moving to a SaaS business model.
Aspect-oriented programming can facilitate de-averaging.
De-averaging is only the beginning if you want to take as much money off the table as possible with the least amount of code. Leaving money on the table only assists your competitors.
I like your points Jeff. We sometimes have to remind our product managers that they cannot just be “secretaries” in meetings. I think sometimes we have to be the subject matter experts. Here’s a story about that, from an actual project of ours:
http://requirements.seilevel.com/blog/2008/04/tips-for-when-you-are-missing-e-in-sme.html
That said, as Mike A talks to here in “Ask, Don’t tell”, you still have to make your users think they are coming up with the requirements and you are just “gathering them”:
http://requirements.seilevel.com/blog/2008/03/ask-dont-tell.html
There is a fairly new book called “Tuned In” by Pragmatic Marketing priniciples (Stull, Myers, Scott) that makes much the same case as this discussion thread. The book is very high level and a bit hyped, but makes essentially the same point as in this thread.
When you are in the early adopter phase of a discontinuous innovation, you need to learn from the client. Your asset is your technology. Your client will give you an application, and that application is your means of acquiring a vertical market.
You can do the listening to the customer stuff in the early vertical and early horizontal/mainstream. But, when you move from those markets, your customer bases change and your business focus will change. You have to partition your listening. Continuing to listen to your existing customers allows them to become the trap that kills your company.
David,
You make excellent points about identifying the unmet needs and gaining insight into customer’s real problems. Recently I moved from managing a B2B product to a B2C online product and the challenges are completely different.
With the B2B product I knew my customer segments, I knew which customers were important and I could approach them directly to identify and understand their problems and unmet needs. Sometimes I have to help them identify and articulate the problem. In most cases the customers have an incentive to spend the time to think and articulate the problems they wanted to solve using my product.
However, with the online product, gaining that insight is much more challenging. While quantitative methods like web analytics give you insight into the customer’s behavior it doesn’t tell you much about why they behave that way. Qualitative analysis probably gives you better insights but how do you know that the customers or potential customers that participate in qualitative analysis represent the needs of mainstream customer base (unless you take a significant sample size which might be expensive)? I would like to hear your thoughts and from others who have found a good way to identify customer’s unmet needs and real problems in an online B2C product.
I meant to address my previous question to Jeff.
B2C looks like late mainstream B2B. I would suggest that you look at Don Pepers One-to-One Marketing books. He segments on lifetime value. Read the new book “Habit.”
Look for B2C marketing advice beyond the web, and beyond technology.
In a recession, you need to get closer to the customer, so de-averaging is what you do. Quantitiative provides average insights and hides opportunities and value. Qualitiative provides large scale trend data, again much too far away from the individual user.
Do you profile your individual users? Do they register and sign in? Do you treat use as a transaction and look for the places where they abandon your site? Have you provided a social environment where they are creating user generated content. They could tell you what they need in that user generated content.
you are funny – gathering requirements is supposed to understand unmet needs..they both mean the same thing..you can be a good story writer.
Your article is similar to: http://articles.techrepublic.com.com/5100-22_11-6112248.html
I think the best practices you highlight are key, but I find the emphasis on “gathering” here more or less just semantic. I think when experienced managers say “gather requirements” they really mean “understand the needs” rather than “harvest”. I think no manager is oblivious to the reality that clients don’t always know what they want or know how to articulate it.
What I like about the other article is its emphasis on ‘negotiating requirements’, because this idea shows the two parties affecting one another in a collaborate process. It implies set ideas on both sides and disagreement, which must be resolved through compromise and convincing.
I elaborated on this relationship in my blog
“Collecting requirements ‘inside the box'”: http://aeuoi.blogspot.com/2010/12/focus-on-it-collecting-requirements.html
In the past, I have been often in situations when one had to, in a sense, influence the client. The idea is that if you have sophisticated end users and a very specific need, you might be able to capture high-level requirements well. But if it’s a custom development, open-ended project, it may be hard for stakeholders to articulate their idea without seeing something tangible first. And if you are implementing a packaged solution, gathering requirements upfront in isolation from the product can lead to problems managing expectations.
This is a very interesting discussion thread, but I still think that the process of identifying ‘requirments’ for a B2C online product are quite different from that of a B2B product.
One obvious way is to create a BETA customer base but that might be quite costly and no gurantee that you may end up identifying or understanding the pain points of your customers.
Although, I will continue to look and post any resources I may find.