Great product management starts with an insightful understanding of your market. Not just understanding a customer, and not even understanding all of your customers, but understanding your target market. What works for you?
The Needs of The Many…
Mr. Spock was on the right track in Wrath of Khan, when he said “logic clearly dictates that the needs of the many outweigh the needs of the few.” And Captain Kirk apparently took Pragmatic Marketing’s training, since he responded, “Or the one.” [That was their original mantra circa 1982, before the more common “Your opinion, while interesting, is irrelevant.”]
It isn’t just the crew of the starship Enterprise that believes an understanding of your target market is critical to product success. I believe it, Pragmatic’s folks teach it, every good product manager I’ve run across embodies this belief. [Note: Steve Yegge has a very intense article where (I think) he believes it too, but believes that it is futile to try and understand a market that doesn’t include you.]
Tools and Techniques
We have a lot of articles here that help you communicate ‘an understanding of the market needs’ with your implementation team – where implementation equals development AND testing.
- Documenting market needs (existing and new markets)
- Making strategic decisions to address those needs
- Engaging with stakeholders to validate needs
- Prioritizing / planning product releases / roadmaps to align a release schedule with targeted needs
- Engaging with stakeholders to clarify needs
- Gathering and documenting requirements details and inter-dependencies
- Validating feasibility / communication of intent with implementation (development and test) teams
- Prototyping and eliciting user feedback
To name a few. We’ve also written about several techniques you can use
- Gathering requirements via interviews
- Applying (and improving) your active listening skills
- Persona development, and differentiation of user goals from corporate goals (and from buyer goals)
The Missing Link
With all the current hub-bub about the bigfoot hoax (“I think I’m going to have a heart attack and die from not surprise!” – Iago, Aladdin), I couldn’t pass up this mug shot.
Collecting the customer-need data, with something more than anecdotal evidence, is tricky. One of the premises of the agile movement is that you can’t, so don’t waste time trying. I’ve always approached it by gathering anecdotal data, looking for root causes to create problem statements, and then working to map back to personas – dangerously extrapolating trends from a handful of datapoints. And it seems to work. But it doesn’t scale. There must be a better way.
I had a great conversation with someone who asked the Austin PMM yahoo group what tools they used for tracking “customer feature requests.” [Thanks again, btw, if you’re reading this.] The requestor was looking for something less than Feature Plan. Just a mechanism for tracking feature requests.
Here’s the problem. A feature request is to a market requirement as a gorilla suit in a block of ice is to a frozen captured Bigfoot. Tracking and managing feature requests isn’t what we actually need to do. Tracking and managing market requirements is what we need to do.
What Do You Do?
OK, so you manage a product that is sold by a sales team. Those sales people, and account managers get feature requests all the time. Or you have a SaaS product, and you built in a feedback mechanism. A 2006 survey of SaaS vendors found that the ratio of feature requests to bug reports was on average, 5 to 1. That’s a lot of feature requests. Your process should look like the following:
- Review feature requests.
- Do something, possibly using some tool(s).
- Determine market needs, prioritize markets (or needs), and update your roadmap…
Share what and how you do it. Some questions I would ask if you were teaching me how:
- Assuming you map ‘features X, Y, and Z’ to an actual ‘requirement A’, how do you chunk those inputs – by persona, by market segment, something else?
- Do you have a way to automate any of the analysis (e.g. mapping a market need to a segment or persona)?
- If you had a magic wand, what would make that job easier?
- Any lessons-learned / advice for new product managers?
- How do you close the feedback loop with the customers who originally submitted all of those feature requests?
Thanks in advance for any responses!
The way FeaturePlan works, and I kind of like it and did like it before I joined Ryma, is by encouraging a line of thinking (i.e. problem statement) between the feature request and the requirement. The tool, and Pragmatic Marketing, encourages this type of process… tell me what you want (enhancement), let me describe what you are trying to do (problem, feature description, use scenario) and then explain it to development (requirements). Something like that. The other piece is that it treats all inputs (enhancements, bugs, win/loss, call reports, etc.) consistently by using them to support problems identified in the market. So all inputs are grouped by the problem statement. Hopefully this did not come across as a sales pitch for FeaturePlan, it just happens to be a tool that supports the way I think.
Stewart, welcome to Tyner Blain, and thanks for sharing! Good to hear that FeaturePlan does organize this stuff in terms of problem statements.
How do you manage the mapping of problem-statements to market-segments (or to buyer or user personas)?
And does this product work in conjunction with a CRM solution like Salesforce or include its own CRM capabilities? How do you get feedback (from the field) into the tool – does the sales rep contact you, then you update featureplan?
Thanks!
Without turning this into a sales pitch for FeaturePlan… FeaturePlan can integrate into Salesforce and we have web forms for contributors to directly enter their data directly in the tool.
>>How do you manage the mapping of problem-statements to market-segments (
>>or to buyer or user personas)?
From FeaturePlan’s perspective we use a market research template to describe segments and tie them to problem statements. FeaturePlan also has a persona template that can be linked to requirements. I polled our product management community (http://tinyurl.com/5vtgwt) in April to see if they thought it was better to link personas to problems, scenarios or requirements and the majority (albeit on 7 responses) thought requirements. I believe it should be problems but can also see needs to link them to requirements and scenarios.
NB: The product management community is open and not just a FeaturePlan community.
Hi Scott,
This is an excellent post, I shared it with our company’s product management team!
>>>>
I had a great conversation with someone who asked the Austin PMM yahoo group what tools they used for tracking “customer feature requests.†… Just a mechanism for tracking feature requests
>>>>
Perhaps they might find it worthwhile to check out our product (Accompa) at http://www.accompa.com?
>>>>
A 2006 survey of SaaS vendors found that the ratio of feature requests to bug reports was on average, 5 to 1. That’s a lot of feature requests.
>>>>
This ratio makes sense to me – it is similar to our experience at our company too.
Thanks Raj, very much. Since this is a recent article, should I assume you finally caught up in reading the backlog? :)
Scott, LOL – yup, more up-to-date now! :)
Great article again. The question of tools is always hot since I haven’t seen a satisfying toolset for PMs yet. Featureplan seems cumbersome (per-seat licenses are so 2000… :-) while Rally + Salesforce.com requires a salesforce using …Salesforce. What do You use for tracking user requests? Excel? Bugzilla?
Thanks Markus, and welcome to Tyner Blain. I’ve used various tools, depending on the client I’m working with. Bug trackers like bugzilla, jira, MKS (yes, really); feedback mechanism “baked into” an application (provides useful contextual info); and inbound email and conversations (from users directly and indirectly).
I’ve managed things in a completely ad-hoc fashion. The best tool I’ve used so far is a concept map, which allows me to relate pain-points with processes, customers, features, and other pain-points. It is free-form, but provides insights. Where it is weak is in metrics and tracking conversations / feedback.
I haven’t seen a solution yet that helps me gain insight, track quantitative elements of the feedback, do demographic analysis, and manage conversations and engagement. Hence the question behind this article.