Inspired-how to create products customer love
- Introduction
- There are some examples on author’s web site, including prototype testing questions and tasks (www.svpg.com/examples), but I missed them before. I think I should browse the web site to study.
- Chapter 1: Key roles and responsibilities
- Product Manager
- assessing product opportunities; (ideas come from everywhere, product manager should take a hard look if it is worth pursuing)
- defining the product to be built; (including the key features and functionalities, user experience, and release criteria) (based on prototype and not papers, the key is to describe the functionality and the behavior of the product to be built)
- Project Manager
- scheduling and tracking;
- The ratios of roles;
- one interaction designer can support two product managers;
- one visual designer can support four interaction designer;
- one product manager supported by 5-10 engineers;
- Product Manager
- Chapter 2: Product management vs. product marketing
- Three situations:
- marketing-driven product: in terms of defining the product, it is largely discounted and ignored;
- two people, one role: no one truly owns the product and then no one ultimately responsible; product manager become little more than spec generation service;
- one person, two roles: marketing means tells the world about the products, but product manager means defining the product, they are different, and it is rare to find someone has both skills;
- the way out;
- clearly define the distinct roles, one responsible for defining, one responsible for marketing;
- it doesn’t mean product marketing is not important, quite the opposite, it is very important, but just different from product defining job;
- Three situations:
- Chapter 3: product management vs. project management
- For internet service company, it is important that the roles be separate; otherwise release will consistently be delayed, and take longer than they should;
- project management is all about executing to deliver the product, and product management is all about discovering a product that is valuable, usable, and feasible;
- Chapter 4: product management vs. design
- design roles includes:
- interaction design;
- visual design;
- rapid prototyping;
- usability testing;
- we also need a software architect make sure the prototype is feasible. More on this later;
- It is not recommended to outsource the interaction design, because it takes a long time to develop a deeper understanding about the target users, and the knowledge is easy to lost when the next release comes up.
- Most enterprise product is weak on interaction design, so create good user experience is the easiest way to differentiate the product from the competition.
- design roles includes:
- Chapter 5: product management vs. engineering
- three ways to come up with better product with engineers:
- get the engineers in front of users and customers; jump start this easily by inviting engineers along to prototype testing; sometimes they will come up better ideas and solutions too.
- enlist the help of engineers in exploring what’s becoming possible as technology develops;
- involve the engineers (or at least a lead engineer) or architect at the very beginning of product discovering process to get clearly assessment of relative costs of different ideas, or to help identify better solutions.
- three ways to help the engineers do their job:
- keep the focus on minimal product;
- once the engineer team begin to develop, do everything to minimize the churn;
- jump on their questions and get the answers as fast as possible;
- how to succeed with remote developers:
- use the high-fidelity prototype as the main communication mechanism;
- it is critical to have someone local to manage all the coordination with remote teams, to make the engineers know who is accountable;
- at least once a quarter the product manager should visit the engineer team to improve the relationship and communication;
- what about outsourcing
- do it not about cost savings, but for finding the right people.
- engineers want to re-write
- dedicate at least 20% to headroom, avoid slamming into ceilings; keep the product infrastructure able to meet the organization needs;
- three ways to come up with better product with engineers:
- Chapter 6: recruiting the product managers
- the personal traits and attitude of great product manager
- passion
- customer empathy: it is very important to empathize the target users.
- intelligence: it is job about insights and judgment, both of which require a sharp mind.
- integrity: he needs to earn the trust and respect of the team members.
- communication skills: he influence the others by persuasion rather than authority.
- skills;
- apply technology: it is a job to find new solution with new technology for existing old problems.
- focus: keep focus on the key problems, and ignore and even reduce those cluttering (unimportant) features.
- the personal traits and attitude of great product manager
- Chapter 11: accessing product opportunities
- ten fundamental questions to answer:
- Exactly what problem will this solve (value proposition);
- For whom do we solve this problem (target market);
- how big is the opportunity (market size);
- how will we measure success (metrics/revenue strategy);
- what alternatives are out there (competitive landscape);
- why are we best suited for this (our differentiation);
- why now (market window);
- how will we get this product to market (go-to-market strategy);
- what factors are critical to success (solution requirements);
- given the above, what’s the recommendation (go or no-go);
- build new or fix old:
- it is the responsibility of the product team to access the profit and the costs, and it is the responsibility of the management team to ensure the company is pursuing the best opportunities available.
- Many times, the best opportunities are sitting right under the company’s nose. This is just another symptom of companies under-investing in design and user experiences.
- find a friend in the finance department, and try to answer below questions:
- do you understand the economics of your product?
- do you know your exact revenue model?
- do you know the total cost of your product?
- do you know how much you pay for the new customer?
- do you know their life time value to the company?
- do you know the return your product generated for the company?
- some information about the product can be uncovered from the financial staff, and expose fantastic opportunities.
- ten fundamental questions to answer:
- Chapter 12: product discovery
- defining the right product
- product opportunity assessment; interview the users and customers; understand the problem to be solved.
- work with interaction designer in prototyping; invite an engineer to evaluate the feasibility or cost of the prototype;
- test prototype with target users to ensure it’s valuable and usable.
- flesh out the details of use cases; review the prototype and spec with engineers;
- keep two versions of product going in parallel. One in execution, one in design for next release.
- defining the right product
- Chapter 13: product principles
- decide what is important
- a set of principles to declare what you believe is more important.
- content:
- what problem are we going to solve;
- for whom will we solve this problem;
- why do we think it is important to do this;
- what objectives do we want to achieve;
- what is the priority of these objectives;
- be completely transparent about decision making process and reasoning, show everyone how you get there, not just following your intuition;
- decide what is important
- Chapter 14: the product council
- timely and definitive product decisions
- a mechanism to get the stakeholders and decision makers together to make timely and informed product decisions;
- purpose
- to set the strategic product directions, allocate product resources and investments, and provide a level of oversight of the company product efforts;
- membership
- typically comprised of a cross-functional set of managers responsible for the product development;
- responsibility
- milestone 1: select the product opportunity to investigate;
- milestone 2: review product opportunity assessments and recommendations, issue go or no-go decisions to begin discovering a solution;
- milestone 3: review product prototype, user testing results, and detailed cost estimates, and issue go or no-go decisions to begin engineering;
- milestone 4: review final product, Q/A status, launch plans, and community impact assessment, issue go or no-go to launch.
- timely and definitive product decisions
- Chapter 15: charter user program
- find at least 6 charter customer
- to make sure you are not producing custom product
- it would be great help for the sales job.
- they need to believe this is a real problem to solve and they need it solved as quickly as possible.
- the benefits to the customers/users if they join:
- they can participate at the very beginning of product design, to make sure it solve the real problem.
- they can test the prototype to make sure the solution is working.
- they can use the product as early as possible once launched.
- if it is very hard to find charter customers, it is likely that we are not chasing a problem that is important.
- explain to the customers we are trying to come up with a general solution, and sell to a large number of customers, not a custom solution working only for them, otherwise we cannot build a real business, and we will go under and they would be left with unsupported, dead-end software. You need to be deeply committed come up with a product that works very well for them.
- find at least 6 charter customer
- Chapter 16: market research
- understanding the capabilities and limitations;
- site observation, user interview, focus group, brain storm, site analytic, customer survey, usability testing, field testing, data mining, personas, competitive analysis;
- all above techniques can help understand user’s needs, but still cannot come up with a good solution.
- understanding the capabilities and limitations;
- Chapter 18: reinventing the product spec.
- it is strongly recommended to use prototype as the main product spec.
- the supplement is some document about business logic, flowchart, use cases, release criteria (reliability, performance, scalability ), platform delivery requirement (installation requirement, list of browsers version that supported). If possible, it is better to annotate this information on the prototype.
- Chapter 19: design vs implementation
- design the user experience before go to the engineering
- don’t do them in one sprint, the design should be one or two sprints ahead.
- only one exception is that there are a lot of infrastructure things to do, then they can proceed in parallel.
- Chapter 20: minimal product
- cutting features or slipping date
- do the cutting at the very beginning, that means the prototype must be minimal functionality. Then when it slip, you have nothing to cut, otherwise either the disabled dog don’t hunt, or the prototype is not the minimal.
- someone from the engineer team, like the architect or lead engineer, must participate in reviewing the prototyping to estimate the cost
- the prototype must be tested with the target users, to make sure they really want it.
- cutting features or slipping date
- Chapter 21: product validation
- feasibility testing: to find out as early as possible if the product is buildable under time-frame;
- usability testing: to make sure the target user can easily figure out how to complete the task;
- valuable testing: to make sure the the target users care about the problem the product will solve, how well it solve, and do they want pay for it.
- Chapter 22: prototype testing
- finding the test subjects
- establish the charter user program;
- if it is a software for business, go to the trade shows;
- if it is a consumer software, use your friend and family network;
- in large company, it is better ask someone in charge of a testing session every two week, invite 10-20 persons come to the company to do test;
- go to the places where the users congregate, and make a road show;
- there is a high no-show rate, so it is better make a personal phone call one day before;
- prepare the test
- defining the task you’ll want to test;
- before show the subject the prototype, let them show you how they deal with the problem usually;
- before tell them the task, let them play the prototype freely for a few minutes, and then ask their for impressions and if they can figure out what problem the prototype can solve.
- questions to ask
- does he use a different product for the same purpose today;
- is this something they do manually or offline;
- is this better than what they use today;
- how likely will you recommend this product to your friend; (or at least ask them to give it a try);
- if possible, structure the problem on a scale, like 0-10. Then we can find out if it improve or not in next round.
- ask them how much they are willing to pay to use this product. (if they cannot answer, they means they are not sure if the product can solve the problem or not)
- finding the test subjects
- Chapter 23: improve existing product
- it is not about adding features, even not about what some particular customers think, or the result of survey, or a focus group, they are all tools, the key is to chasing the metric whick we set up at the beginning to measure success.
- below are the ways we can collect information to help us understand why and how to imporve the merics:
- site analytics;
- sales department;
- customer serivce;
- real user test;
- focus on relentlessly pursuing metrics by studying live use and working the numbers in the right direction.
- Chapter 24: gentle deployment
- the way to avoid user abuse
- notice in advance;
- running two versions in parallel;
- double Q/A efforts to ensure not rollback;
- regional deployment;
- Chapter 25:rapid response
- keep the whole team members together for one or two weeks after release, and then they can response quickly once the issues arise.
- Chapter 26: succeeding with agile methods
- the design work must be one or two sprints ahead of engineering.
- let engineers break up the sprint into whatever granularity they prefer. Let them chunk the functionality into sprints as they see fit.
- don’t release every sprint except the product manager think the functionality is sufficient.
- agile stem from custom software, so it is must to understand the difference between product software and custom software, like the interaction design, visual design, and architecture design.
- Chapter 27: succeeding with waterfall processes
- do prototype and test it before give it to the engineering.
- Chapter 30: succeding in the large companies
- learn how decisions are made inside your organization;
- building relationship before you need them. Make friends;
- long live skunk works;
- just get it done;
- pick your battles;
- build consensus before important meetings where decision are required.
- share information;
- put your manager to work;
- evangelize;
- Chapter 31: learn from Apple
- hardware serves the software;
- software serves the user experience;
- user experience serve the emotion;
- Chapter 32: beware of specials
- don’t fall down the slippery slopes;
- it is natural for the customers to describe their problems in terms of solution rather than underlying problem itself; it is the product manager’s job to tease out the core issues and needs.
- consider looking at how to keep your product general purpose but allow the product to be extended by a solution provider.
- Chapter 33: the new old thing
- two key methods that smart company use to create a winning product in mature market:
- they understand the target market and where the current products fall short; product usability test is a good technique to do this, either your own product or your competitor’s;
- great product leaders know what is possible is always changing. New technologies enable new solutions that may hot have been possible and feasible until now.
- great product manager combine with what is desirable with what is just now possible.
- two key methods that smart company use to create a winning product in mature market:
- Chapter 34: fear, greed, lust
- the role of emotion in products: people buy products largely out of emotional reasons;
- the dominant emotion for enterprise is fear and greed. For consumer, it is more personal, like loneliness, love or lust, pride, greed.
- when doing prototype testing, you should also take this opportunity to find out what emotion driving the users, and how well your product meet that emotion.
- Chapter 35: the emotional adoption curve
- an interview with Jeff
- focus on the most miserable thing people have to deal with everyday.
- focus on the group of irrationals, they will exaggerate their emotions;
- look for ways tap into these emotions with features and all other things;
- the freshman emotion: loneliness, insecurity, fear, frustration, anger,
- an interview with Jeff
- Chapter 36: usability vs. aesthetics
- both are important, but require different skills; it is not easy to find a person can do both.
- Chapter 37: keys to consumer internet service product
- usability;
- personas: divide your users into several important personas, examine every new feature with them;
- scalability: dedicate 20% from day one;
- availability;
- customer support;
- privacy and data protection;
- viral marketing;
- globalization;
- gentle deployment;
- community management;
- Chapter 38: keys to enterprise products
- usability;
- product actually needs to work;
- specials: avoiding specials takes a lot of discipline;
- customers and charter user program;
- designing for the sales channel;
- the customer versus the user: there are different types of end users, system administrators, management, and other business applications;
- product installation;
- product customization, configuration, and integration.
- product update.
- the sales process: use the internet too.
- Chapter 39: keys to platform products
- high leverage but not easy.
- the priority: end-users > application providers > developers
- Chapter 40: best practices summary
- the role of product management: not marketing, not project management;
- the role of user experience: it is all important.
- opportunity assessment: lightweight, to-the-point assessment replace the old MRD. what problem to solve, who solve for, how to measure success, before jump into solution.
- charter user program.
- product principles
- personas
- focus on discovery.
- the use of prototype
- test prototype with target users.
- measure to improve: analyzing the product actual use, driving the product to improve the key metrics.
- Chapter 41: product manager worry list
- is my product compelling to the target customers;
- have we made the product as easy to use as humanly possible.
- will this product succeed against competition; not competition now, but the time when we ship.
- do I know the customers who will buy this product.
- is my product truly differentiated; can I tell this differentiation to a company executive in 2 minutes, to customer in 1 minutes, to industry analysis in 30 seconds?
- will the product actually work?
- is the product a whole product. how will customer actually think about and buy the product. is it consistent with how we plan to sell it.
- Are the product strengths consistent with what’s important to our customer? Are we positioning these strengths as aggressively as possible.
- Is the product worth money? How much money? Why? Can the customer get it cheaper elsewhere.
- Do I understand what the rest of product team think is good about the product? Is it consistent with my own view?
Inspired-how to create products customer love
https://ccw1078.github.io/2016/02/03/Inspired/