5 Common Mistakes to Avoid in Product Ideation
In the last blog post, I wrote about the art of customer insight and how you can arrive at a customer insight through empathy. After insights, the next stop in your product journey is ideation. It’s in the ideation phase that product managers, UX designers, and engineers come together to tap into key insight and generate a broad range of new ideas for how they can deliver a benefit to the customer. It’s a creative phase where a lot of magic happens. Unfortunately, it’s in this phase that many product managers falter. They make common mistakes that constrain them in their creative process or make their ideas narrow or ineffective.
Let’s look at the top 5 ideation mistakes and how you can avoid them.
Mistake #1 — Lack of clarity on user personas
“Who, precisely, are you trying to reach?” — Seth Godin
Personas help to humanize your target users. They are constructed by capturing key attributes of your users such as demographic profile, role, title, responsibilities, daily tasks, skill sets, and goals. If you don’t clearly identify your target user persona, you could be laying the foundation for ill-conceived product ideas. Look for these common indications that you may be making mistakes with your user personas -
Your personas are too vague or generic — Don’t talk about your customers in general terms as though anyone in any company could use your product — e.g., an “enterprise user” could mean a whole array of enterprise roles that have very different skill sets, have different mindsets, and typically use different toolsets. Be specific and use distinct personas whenever you can — e.g., an IT manager or a security engineer.
You’re mixing up your personas — Catch yourself when your idea starts talking about one persona and soon moves to another, creating a hodgepodge of a use case that is neither coherent nor realistic. For example, at Druva, when my team ideated on product concepts for legal users to implement a legal hold on an employee’s data and then analyze it, we were mixing up tasks done by an IT administrator with those of the legal user. There was enough confusion for us to go back to the drawing board and clarify the personas involved.
You’re targeting the wrong persona — I’ve seen many product ideas that offer little use to the target user. For example, a new interactive authoring capability for authoring complex custom queries will not appeal to a target IT manager, who’s not a highly-skilled developer. Similarly, new features that improve the speed and performance of products but add costs will be looked at negatively by an economic buyer despite appealing to a technical buyer. In complex enterprise sales, product managers must clearly distinguish the needs of the end user from those of the technical buyer and the economic buyer.
Mistake #2 — Not being crisp on the customer need
“If you only have a hammer, you tend to see every problem as a nail.” — Abraham Maslow
Always be crisp about the specific customer need in question. For example, is the customer need basic safety or higher-order efficiency? Are you talking about a customer need or a want? To answer these questions, evaluate where in your customer’s hierarchy of needs your new idea fits. Here are some examples of different kinds of customer needs that follow a hierarchy -
Security & Availability — Customers will need these basic needs met before they can entertain anything else — e.g., “Is my data safe?”, “Will my data be available to me every time I need it?”. At AWS, customers expect all services to be secure and reliable, so these needs take precedence over product features.
Utility — These are customers’ needs around functionality that need to be met by your product — e.g., being able to replicate data across regions, being able to define a policy, and implementing it across multiple applications in the cloud.
Effectiveness/Efficiency — These needs cover reliable and error-free completion of tasks, speed of completion, ease of use, customer savings in time, effort, and cost, etc.
Satisfaction — These needs contribute to your customer’s overall satisfaction with the product — e.g, “Does it integrate with my existing systems?”, “Does it allow me to customize?”
Self-fulfillment — These needs allow your customer to focus on higher-value things — e.g., “Is it making me better in my job?”
You should first make sure that your customers’ basic needs are met before you ideate about something higher in the hierarchy. A speed improvement of 10% is not going to matter to your customer if they view their data as being not safe with your service. Next, evaluate where your idea is with respect to what’s already met by your product. For example, a 10% speed improvement may just be a customer want (vs. need) if your product already delivers an acceptable speed to them; but it could be an actual need if the 10% improvement is needed by them for certain mission-critical applications..
Mistake #3 — Losing track of the why (customer insight)
“There is nothing so terrible as activity without insight.” — Johann Wolfgang von Goethe
Your ideas may veer off into features that are misaligned with the target user if they lose track of your customer’s motivation. As an example, the need for a cloud administrator to disallow certain cloud services for their developers can be solved very differently knowing whether the motivation is to save costs or to comply with regulatory requirements. In another example, at Intuit, my team worked to improve an accountant’s tax preparation workflow with their end customer, a small business. The accountant’s motivation to automate the collection of customer information was to maximize productivity by shifting from low-value manual entry to higher-order tax advice. Interestingly, the accountant’s motivation was misaligned with the customers’ motivation, which was to keep their work simple and maximize tax savings. Understanding the motivation for each persona is super important in developing ideas that work.
Mistake #4 — Not being crisp in your problem statement
“There are no right answers to wrong questions.” — Ursula K. Le Gui
A problem statement or use case is best expressed in the following format -
“As <a user persona>, I need to <customer need> because <the why or the customer insight>”.
One common ideation mistake is not connecting the individual components (user, need, insight) to frame the right problem statement. As an example -
“As a business user, I need to see a dashboard because I need instant visibility into my environment”
Here the need “to see a dashboard” is not exactly a need, it’s a solution disguised as a need. The stated insight of “needing instant visibility” is not actually an insight, it’s the actual need. The real customer motivation is actually missing, which should be “because I want to be able to respond to business-critical issues as soon as I can”. An ideation that starts with the above problem statement is going to pre-suppose a solution and miss opportunities for the dashboard to incorporate meaningful actions and workflows.
Another common mistake is making the problem statement too broad -
“As a security professional, I need to be able to assess my risk and compliance posture because I need to be compliant”.
Everything about this problem statement is broad. Are all “security professionals” the same? What does “assessing my risk and compliance posture” actually mean? What does “need to be compliant” refer to? The right way of expressing this problem is as follows -
“As a security auditor, I need to be able to view in real-time if my cloud applications comply with HIPAA requirements because my company deals with protected health information and is required to ensure HIPAA compliance”.
Mistake #5 — Not framing the ideation with the right question
“If I had an hour to solve a problem and my life depended on the solution, I would spend the first 55 minutes determining the proper question to ask, for once I know the proper question, I could solve the problem in less than five minutes.” — Albert Einstein
A common ideation mistake is to enter the phase with a problem statement that may force a certain mindset with a narrow view of possibilities. Instead, if you rephrase your problem statement as an open question, your ideation becomes conducive to fertile brainstorming where magic can happen. A question, not a statement, is the basis for ideation.
“How might we” or “In what ways might we” are proven ways to start framing your open ideation questions. Here are some good examples -
“How might we provide instant visibility to cloud security engineers so they can quickly respond to critical security events?”
“In what ways might we speed up an accountant’s collection of required information from her customers?”
There may not seem to be a significant difference between an open ideation question and an associated problem statement, but in an ideation phase, a question makes all the difference. A question puts you in an inquiry mode, sparks creativity, and opens up possibilities for imagination and inventions. That’s exactly how you should enter the ideation phase.
Happy ideating!
Chandar
