These are not best practices that I am outlining here. While they could be, it is finally dependent on the personal comfort of the individual doing the research.
At ISB I had opted for the Market Research elective, but attended all of one class before switching to another. (Not that it was a particularly intelligent choice, but nevertheless.) But that course was more about primary market research. The most important kind for a product manager. But secondary research has a critical role to play as well.
I have written previously about sources of secondary research that product managers can use to do secondary research on the cheap. In this post I would like to highlight the steps I typically take to do secondary research. It is still probably not perfect but using this thought model has helped me immensely in getting more out of my secondary research activities than previously.
List your Questions
This is the first step. Even before you worry about collecting data, list out the big questions that you want answers to as a result of this research. However, remember that this list is not supposed to be a writ in stone. As you move ahead with your research you might find answers to which you have no questions listed. It is then time to revisit the list of questions and update it. The benefit of this step is to give you a proper direction in your research so that you do not get lost in a maze of unrelated or unnecessary information.
Once you have the basic questions ready it is time for collecting data. Just collecting. Not reading. Not analyzing. Not summarizing. Just collecting. Its a personal experience that whenever I start reading through the data I get new questions and new thoughts that derail me from the primary research objectives. Also by concentrating on one task you will be more efficient in collecting data.
Analyze the data
Once you are satisfied with the quantum of collected data, you should begin analyzing the data. Read through each item with the questions you have already prepared in mind. Add answers to those questions as and when you find them. Or create new questions to justify answers you find.
Synthesize the analysis
This is the final step to the process. Synthesize the analysis into a coherent document, thought-paper or whatever you are comfortable with. If you are comfortable with the dump from the analysis step you might even choose to skip this step completely. However, if you still have unanswered questions in your list, you should go back to the data collection step if you still feel it is important to answer these questions.
I hope you find this process useful. Have I missed any thing here? Are there some better ways to do structured secondary research? Do let me know in the comments below.
In new product design one of the key tasks is to maintain a balance between the ‘points of parity’ and the ‘points of difference’ with competing products.
‘Points of parity’ are hygiene factors, features that you must support because your competitors have them. But more importantly because users of your competitors products want them. ‘Points of difference’ are how you effectively differentiate your product from the others.
On the face of it, ‘points of difference’ are clearly the more difficult task. But in reality it can be simpler because you know what your competitors do not have. And for this same reason choosing ‘points of parity’ can be difficult.
What features do you keep and which ones do you drop? You need to know how users view these features. Think of your competitor as a feature bloated software where users hardly use 80% of the features. You could easily drop them, add a few of your differentiators and make the product easier to use.
But you still need to take a call on those 20% to keep. You could keep all and make it difficult for your customers to find your differentiators.
Once a new product is ready for launch it can be a harrowing task to convince internal users to do beta testing for you. While this is a highly desirable step before a public beta release, it is not a simple task to incentivize employees within your organization who are not part of the product team to do it for you.
Forrester reports on how Microsoft has been doing this successfully for some time now through the use of “productivity games”. As with other games, these are still not easy to create. For one they have to be engaging enough and fun enough for people to try it. And there must be a clear reward mechanism (like leaderboards, prizes) to incentivize participation.
While this may have worked well for Microsoft and maybe other companies as well, it may not be very easy to convince your bosses to have employees playing games. A very open culture and a clear understanding of the improvement sought is necessary for this kind of initiative to work.
If you are thinking of getting started here are some tips from the article:
- Assess whether or not you can actually create a game. A good game is a complicated thing to create because you have to get gaming dynamics — the problem set and the incentives for completing tasks — correct. So, you have to ask yourself what you know about game design. If these capabilities don’t exist internally, you have to find them externally.
- Be prepared to be an evangelist. The guys at Microsoft who created productivity games were also the people who propagated its use. Ross Smith, a defect test manager and one of the serious games developers at Microsoft, has appeared on panels, written papers, and given presentations to promote this work.
- Keep the focus of the game narrow. The productivity game developers weren’t trying to cure all of the world’s problems — they were simply trying to get people to participate in product testing. Similarly, if you’re looking to create a game, you have to identify the business you want to solve and keep the focus on that specific problem.
Source: Product Managers Take Note: Microsoft Is Using Serious Games To Product Test (And You Can Too)
I was trying to book a (bus) ticket today for my brother-in-law to come and spend the extended weekend with us. When it comes to bus tickets I always rely on Redbus. However, given the high demand none was available and I headed over to MakeMyTrip to take an outside chance. And the way they present search results to users got me thinking.
Here is what you see on Redbus when you search for a ticket. Very clearly showing the availability in every bus. On mouse-over also showing the pick up and drop off point and also a summary snapshot of passenger reviews. You basically get a complete picture right on the search result page.
And here is how the experience at MakeMyTrip is. Empty seats are not listed anywhere. Some of the arrival times are also missing. There is input duplication with boarding point being selectable on the search results as well as when you click on choose seats.
So how do you actually find out the availability? Click on ‘Choose Seats’. A pop-up opens up in its own time. And bingo! There you have it, “Sorry, you are late. Seats are sold out. Try another bus.”
My point is not to compare the service of Redbus and MakeMyTrip but to make the point that providing feedback to the user is an important aspect of the whole experience of using a product or a service. The point is to make sure that the user is not surprised and lost.
When someone performs an action, here search for a bus, there are certain bits of information that she expects to get immediately. Here it would be the departure and arrival times and availability. Providing this information immediately to the user improves the experience of the interaction. And makes her come back next time.
Do you have other examples where you were frustrated by the lack of feedback? Or, maybe, too much of it?
One of the foremost tasks of a product manager is to define the product. And this is the most difficult of all the tasks a product manager has to perform. In the product definition stage the product manager has to:
- Ideate on the product concept
- Talk to potential customers
- Analyze all target markets
in order to:
- Elucidate the market problem and the opportunity therein
- Build the business case
- Analyze competition
- List all market requirements
To do all this successfully the product manager has to be good at market research. If you are working within a big company with enough budget this may not be too difficult a task. You can easily buy research reports, hire a market research company or do a focus group study.
But what if there is not budget until the product is approved? What if you are working at a startup with no scope of such discretionary spending? This is when you need to tap into the power of the Internet. However, finding the right information is not always easy on the Internet. Here are some steps/sources that might help you mitigate the problem:
- Web Search: The most obvious place to start is web search. But do not limit yourself to your favorite search engine. Try both Bing and Google. And use the advanced search features for better results.
- Image Search and Flickr: This is not so obvious. But I have found this to be a useful source. You never know what images of graphs and trends this will throw up making your life easier.
- Blog Search: Specifically search within the blogosphere if you know that some expensive report exists out there which would be useful for you. Some helpful blogger would have read it and summarized it for you. May be even include a couple of those charts you are dying for.
- Analyst Blogs: Look up Forrester, Gartner, Nielsen, comScore and other analyst/market research firm blogs that operate in your domain. More often than not they will report summary findings of their research in a blog post. That may be a good point to build your case to buy that report.
- Management Consulting Blogs: Blogs of McKinsey, Booz & Co and BCG could also have analysis and information about your industry and customers.
- Slideshare: Look up for those presentation on customer needs, market dynamics and vendor analysis.
- Scribd: Same as Slideshare, but documents only.
- Twitter: You cannot ignore Twitter today. However, suggest you to use the advanced Twitter search or specialized Twitter search engines. The default Twitter search is very bad at removing noise and you might get a whole long lost of a popular link retweeted by thousands. Not very helpful.
This is by and large the places I look for when I do my secondary research, but is is no way exhaustive. But following this list is a better way to approach the problem than going on clicking random links on Google and Bing.
What do you think? Are there other sources that we should definitely consider? Please leave your recommendations and suggestions in the comments below.
When you are in early stage product development, a user story is one of the most important items that you should consider. A user story is a description of a goal/scenario a (typical) user would want to achieve with the product.
Why is a user story so important?
- Whether you are building a product within an organization or you are a start-up, you have to sell your product to those who are willing to sponsor the development. If your product addresses a very clear or common problem and there is a demonstrable market out there, your job becomes easy. But still it may not be suitably clear to everyone how your product will be of help.
- You want to partner with someone to co-create the product or have them tweak a product of theirs to work with your product.
- Explain clearly to the engineering and quality teams a typical use case and the relationship between the product modules.
- Pitch your product to potential customers.
- Consistency when different members of the product team evangelize the product at separate locations at different times.
Here are some steps that you could consider when coming up with a user story.
- List the product modules and their features (on a whiteboard or anyplace the team can see easily) so it is easier to visualize the relationship between them when writing the story. This is important to ensure that your story includes only what your product offers currently while leaving scope for expansion.
- Identify the user who is going to use the product and make the story compelling for her. It makes no sense to write a story with the CEO in mind when the CFO is the one who will be using the product.
- Identify one problem in an area that the user will be responsible for. Else she’ll not be interested.
- Then show how the product helps identify that problem and solve it. It is important here to cover as much of the product features as possible without reaching novel length. Not all features may be useful for a particular person you are pitching to, but will at least include those that matter to her.
- Link it back to a beneficial outcome solving the original problem to close the loop. If it doesn’t help the user, it doesn’t help you. Period. And the user must realize the benefits.
What are some other considerations for writing user stories? What are some other reasons for wiritng a user story? Do you have an example where a user story failed and what did you learn from it?
[image: Flickr/Anna Gutermuth]
As you start work on a new product you may need to create a point-of view document for it. This is really a step before the full fledged business plan and may or may not be required in every organization. But it is a good place to start since you can easily extend it to make the business plan.
Here is what you might want to do:
- Start off with snippets of information highlighting the problems your product is trying to solve. Collect real data and spruce it up with appropriate imagery. For example, something like “people spend x% of their work time on social networks to gain knowledge about their work”.
- Create a summary slide/table to consolidate those problems.
- Highlight “what-if” scenarios to create awareness of the solution that your product will offer. For example, if you are building a enterprise social network you could highlight some thing like “what if your employees could interact with each other to share knowledge, best practices and information”. You get the drift, right.
- Introduce the product with its modules/functionality and the relationship between them. (Add a business architecture diagram for those who might want to know about your product in greater detail.)
- Add market data about your industry and the size of the addressable market. Revenue projections, costs and other financial details can go in the formal business plan.
- Do not forget to add references to the sources from where you got all the information in an appendix slide.
- Also add any other relevant information in greater detail in the appendix slides. This is in case you need to mail out the point-of-view to others and you don’t have the opportunity to talk them through it.
[image: Flickr/Richard Moross]