Sunday, August 12, 2012

Problem Solution Framework

Managing a product often digresses to managing projects, business analysis, product marketing. It has some functional overlap and interdependence with all these activities but is a big core activity in itself. The main issue with digressing into peripheral tasks is that those tasks are typically very engaging and one may potentially lose track of product management altogether. The biggest opportunity and challenge for Product managers is to look at the problem(s) and possible solution(s) ignoring the benefits/limitations of technology. Then, the product manager should constantly strive to leverage technology to derive product(s) that is closer to the possible solution(s).

I’d try and explain the point with an example. Say you have an idea for a camera app or have been tasked to create one. As a product manager, one should never think in terms of creating a camera app. Try to think in terms of the ideal user. What is the user’s routine, what does the user think and do from daybreak till sleep? How do they behave on weekends, on travel, and on vacation? What affects the user – money, love, family, friends, politics, religion. What problems can be identified in the current pattern? And what are possible fixes (in the context of the need for visual memory)? Now, this problem-solution framework works as a guideline to derive your products.

Deriving Product from Solution

Product Management is all about balancing Tech, Usability, and Business. 

Technology (Smartphone, Hardware, software, app) usually is a means to get a tangible solution. Product(s) may not even be able to provide the entire solution, but it is ok as long as it solves some part of the problem for the users. Product may evolve with time and technology to be as close to a solution as possible, but, it is an ongoing process. So technology is the first filter, where you scrape out stuff that is not feasible. Ideally, it can be done between product management and engineering (both development and QA). Once the problem and solution is well understood by engineering, PMs can gather their inputs, take ideas, rate them and come up with a feature set. Ideally, it would be best to facilitate the discussion between all engineering stakeholders and get their buy-in on the set of feasible feature set. Or, if this exercise is for one feature, it should cover all use cases. Including QA and Design is optional but I’ve seen them providing great inputs during contention.

Usability: The feasible feature set needs to be made usable. It is important to identify the most salient features, simple flows, and complicated flows. While discussing the feature set among PM, Marketing and Design the focus should be on how to make users understand the most salient feature instantly through an extremely simple flow. Once they are hooked they’d be able to do the complex workflows as well. Another important thing is to make users know the importance of every step that they take. Take extra care to tell them how does it help them. Not at the end of the flow, but at every step. Messaging plays a key role here.

Business: Once a feature set is usable, it is fit to show the visual representation (wireframes, etc.) to executives, sales, and marketing teams and get their buy-in. By this time PM should have an idea of the approximate investment required, measurement metric of success, and expected returns. It may also be important to bring the long-term vision and how the solution aligns to it in the picture. Also, the roadmap for future progress.

The product ideation framework can always serve as a guideline for the product(s). Instead of fretting about the next great feature, the Product manager can actually focus on adding more value to the product and thus bring more value to the consumer.

So product ideation framework seems to be a big name. I am just calling it what it is for my own use. I’ve tried to jot down a few general questions from my interactions with cross-functional teams so far. Not sure, how applicable it is for everyone, but, I am able to reuse them in my dealings.

Problem

  • What is the problem? Whose problem is it? Will they pay or invest time to solve this problem?
  • What is possible to create/change

Solution

  • Does it solve a problem or enrich the user’s experience in some other way?
  • How does it solve the problem? Is that the most elegant way to solve it?
  • Whose problem is it solving (again)? Is it for all of your users or targeted at a specific type of user?

Here's the funnel for decision making:

Technology filter

  • Can we implement this solution? How much of it can be implemented by our team?
  • What tools can we leverage?
  • Will target consumers be equipped with those tools?
  • Is the solution valid and good even if a part of it cannot be implemented?
  • Can the leftover be implemented in the future? If yes add it to the roadmap.
  • What is the investment required?
  • Is Engineering excited about this?

Usability filter

  • What is the most salient feature(s)?
  • How complicated are they? (Simple/Moderate/Complex)
  • Can moderate and complex flows be broken down into simple and moderately complex flows?
  • Can each step be described in one or two words?
  • Is the user informed of how each step is taking them close to a solution?

Business filter

  • Does it align with our vision and long-term goals?
  • What will be the success metric? When and how can we measure it?
  • What is the investment required? (again)
  • What would be the qualitative/quantitative ROI?
  • Risks associated with having and not having the said solution?
  • Does it help sales, marketing?
  • How big can this get? How is it going to shape up in the future?

Consumer feedback

Does the feature/product delight the user?

---

If you like what you read, do leave a comment!

PM is a Double Agent

Most Popular on this blog