Automasean

10 truths to keep in mind on every product effort:

  1. The job of product manager is to discover a product that is valuable, usable and feasible.
  2. Product discovery is a collaboration between the product manager, interaction designer and software architect.
  3. Engineering is important and difficult, but UX design is even more important, and usually more difficult.
  4. Engineers are typically very poor at UX design - engineers think in terms of implementation models, but users think in terms of conceptual models.
  5. UX design means both interaction design and visual design (and for hardware-based devices, industrial design).
  6. Functionality (product requirements) and UX design are inherently intertwined.
  7. Product ideas must be tested - early and often - on actual target users in order to come up with a product that is valuable and usable.
  8. We need a high-fidelity prototype so we can quickly, easily and frequently test our ideas on real users using a realistic UX.
  9. The job of the product manager is to identify the MVP that meets the objectives - valuable, usable and feasible - minimizing time to market and user complexity.
  10. Once this MVP has been discovered and validated, it is not something that you can piecemeal and expect the same results.

Staffing

There should only be one product manager accountable for a product.

When interviewing prospective product managers, it's helpful to not look so much for what they already know but for each of their products, what did they need to learn, how long did it take them and how did they apply that knowledge?

Every new product manager needs roughly three months of hard learning before you can entrust them with the responsibility of guiding a product.

  • immerse with target users/customers
  • get educated on the relevant technologies
  • study the market/competitive landscape

If you micromanage your product managers, they will not step up and take ownership the way you need them to.

It is critical to have someone that the engineering team can get fast answers/feedback from. If not the product manager, someone close to them.

Ideally, the product organization includes the design team. The interaction between product management and UX design absolutely needs to be as close as possible.

Design-related roles (possible to find people that can handle more than one):

  • Interaction Design - these people are responsible for developing a deep understanding of the target users and coming up with the tasks, navigation and flow that are both valuable and usable. Generally, the interaction designer maps product requirements to a design represented by wireframes and passes them to the visual designer.
  • Visual Design - these people put the flesh on the wireframe and create the actual pages and user interface look and feel. This includes everything from the precise layout, colors and fonts but, more importantly, the visual design communicates and evokes emotion in the product (which is far more important than you may think).
  • Rapid Prototyping - the prototypes work to capture the ideas of the product manager and designers into a prototype that can be tested on real users and iterated upon.
  • Usability Testing - this person specializes in research and analysis of the users, evaluating whether products or prototypes allow a given user to easily achieve objectives. It includes recruiting appropriate test subjects, administering the tests, evaluating the results and recommending alternatives.

Given the option it's a better choice to outsource QA vs design.

If you're trying to create inspiring products, for most professional positions, outsourcing should not be about cost savings - it should be about assembling the right people for the product. This might mean hiring remotely.

Product discovery

Product Opportunity Assessment - 10 fundamental questions for product managers

  1. Exactly what problem will this solve? (value proposition)
  2. For whom do we solve that problem? (target market)
  3. How big is the opportunity? (market size)
  4. How will we measure success? (metrics/revenue strategy)
  5. What alternatives are out there now? (competitive landscape)
  6. Why are we best suited to pursue this? (our differentiator)
  7. Why now? (market window)
  8. How will we get this product to market? (go-to-market strategy)
    • describing how the product will be sold can have very significant impact on product requirements
  9. What factors are critical to success? (solution requirements)
    • not the actual solution
  10. Given the above, what's the recommendation? (go or no-go)

General order of operations for discovery:

  1. Product Opportunity Assessment
  2. Spend quality time interviewing real users, identifying a preliminary set of requirements
  3. Work with a designer on a prototype
  4. Conduct user testing with the prototype
  5. Flesh out details of the use cases
  6. Review the prototype and spec with engineering This process is very hard to time-box. If you rush it you run the risk of building the wrong thing. Sometimes this is needed in startups.

UX design needs to happen before the implementation begins.

Requirements for a good and useful product spec:

  • must describe the full UX
    • product requirements, user interaction design and visual design
  • must have a prototype to accurately represent the behavior of the software
    • don't need to demo every single edge case
  • must communicate in a way that's digestible to the entire audience
    • engineering, QA, customer service, marketing, site operations, sales and executives
  • must be a single source-of-truth
  • must change to reflect any adjustments made since initial publication

Unfortunately, companies often use the engineering organization to build a very, very expensive prototype and they use the live customers as unwitting test subjects.

... testing your ideas with real users is probably the single most important activity in your job as product manager.

Just as you wouldn't allow an engineer to ship code just because he or she believed it was good, you must test that code to be sure.

The product discovery process is about answering these questions:

  • What technologies can I apply to solve this problem in a better way?
  • What should the UX be?

Personas

  • help frame who the product is for
  • help guard against building products for ourselves
  • help when deciding what should be included in a release Personas should be prioritized. Ideally focus on one persona per release.

Build new vs improve existing? In reality, many products are poorly done and rather than improve a product to the point where it can generate real revenue and success, many organizations view it as easier to create a new product instead. But unless they change the way they produce that new product, they're likely going to end up with yet another under-performing product in need of improvement.

Doing explicitly-defined work for a specific customer (typically in exchange for their agreement to purchase your product) is very dangerous. Short-term revenue might be nice but potentially hurting the overall customer experience outweighs the short-term gains.

Always keep two versions of a product going in parallel. As soon as you start the engineering for release 1.0 then you start up the discovery for release 2.0 in parallel. Warning: you need to be careful that this approach doesn't detract from the execution work for the current project.

You and your designers should always try and be one or two sprints ahead of your team.

Engineering

It doesn't matter how good your engineering team is if they are not given something worthwhile to build.

At least as important as "building the thing right" is "building the right thing" (a product that is valuable, usable and feasible).

It's useful to have a software architect review the progress and prototypes to ensure feasibility.

Get your engineers in front of users and customers. Not only will they learn a great deal from seeing users struggle first hand, but they will get a better appreciation for the issues and their severity. This is often the inspiration for much better ideas and solutions. You can jumpstart this easily by inviting an engineer along to your prototype testing.

We tend to want to think of our users as we thing of ourselves and our friends. However, the target market very likely has quite different values, priorities, perceptions, tolerances, experiences and technical understandings.

Finance

Understanding the economics of your product:

  • Do you know your exact revenue model?
  • Do you know how much you pay for each new customer?
  • Do you know their lifetime value to the company?
  • Do you know the return your product has generated for the company?
  • Do you know the total costs of your product?

Befriend someone in finance to help gain insight here. Can ask the CFO for a person they recommend.

Market Research

Try to get at least 6 happy, live, reference-able customers from your target market (you'll probably need to start with 8-10). They make the product discovery/refinement easier and their testimonials make marketing much easier. Offer the product for free until they have a product they love.

If you have a ton of trouble recruiting these customers you may not be solving a problem worth solving. Usually, if the problem is important enough, prospective customers will want to participate.

Tools:

  • Customer surveys
  • Site analytics
  • Data mining
    • site analytics, billing data, user data, etc.
    • think Tableau
  • On-site visits
    • expensive and infrequent but worth it
    • plan accordingly
  • Personas
  • Usability testing
  • Analysis of your competition

The product manager should attend every user interview, every site visit, every usability test and every charter user program meeting that pertains directly to their product.

These techniques can help answer these questions:

  • Do you understand who your users really are?
  • How are users using your product?
  • Can users figure out how to use your product? Where do they stumble?
  • Why do users use your product?
  • What do users like about your product?
  • What do you users want added to or changed in your product?

Product marketing and product management are distinct and each contribute to one another. The product marketing person will be one of several key sources of input to product requirements owned by the product manager. The product manager will be one of the several key sources of input to marketing messages owned by product marketing.

All of Chapter 22 is great for learning about how to conduct effective usability testing.

Misc

Winning products come from the deep understanding of the user's needs combined with an equally deep understanding of what's just now possible.

"Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity." - General George S Patton, Jr.

"Most people wander around in the dark and bitch about it being dark, instead of learning where the light switches are." - David Weiden

NPS is a good metric but shouldn't be the only one.

When working in a large company there are many reasons for constant change in direction:

  • managerial hierarchies with differing incentives at different levels
  • outside influence:
    • competitive pressures
    • changing technologies
    • mergers/acquisitions
    • business development deals
    • budget
    • staffing constraints

This is part of the cost of working at a large firm. The benefit, however, is that if you can find a way to leverage the resources of your large company, you can have a dramatic impact on the marketplace on a scale that's hard to match at a small firm.

Rapid response phase - begins at launch and lasts typically a few days to a week. This is all about responding quickly to what you learn once the product has launched.

More often than not, innovation is about salving an existing problem in a new way rather than solving an entirely new problem. Watching people struggle with existing solutions is a great way to highlight innovation opportunities. This could be the product your building or a competitor's product.

Interesting insight on the iPhone as a product - "The Hardware Serves the Software" We're seeing this today with folks designing hardware specifically for machine learning algorithms.

Platform products need to meet the needs of all three stakeholders:

  • The application providers - the businesses that choose to use your platform to build their solution.
    • cares about pricing, licensing, quality, support, global availability, back-up plans if your company goes away, etc.
  • The developers - those who work for the application providers and who write their software using your platform services.
    • cares about easily creating maintainable, reliable code in the languages they want to use, working with their favorite tools and infrastructure.
  • The end-users - the ones who run the application provider's product(s) and ultimately use your service.
    • care about the end result

Product manager worry list:

  1. Is my product compelling to our target customer?
  2. Have we made this product as easy to use as humanly possible?
  3. Will this product succeed against the competition? Not today's competition, but the competition that will be in the market when we ship?
  4. Do I know customers who will really buy this product? Not the product I wish we were going to build, but what we're really going to build?
  5. Is my product truly differentiated? Can I explain the differentiation to a company executive in 2 minutes? To a smart customer in 1 minute? To an industry analyst in 30 seconds?
  6. Will the product actually work?
  7. Is the product a whole product? How will customers actually think about and buy the product? Is it consistent with how we plan to sell it?
  8. Are the product's strength consistent with what's important to our customers? Are we positioning these strengths as aggressively as possible?
  9. Is the product worth money? How much money? Why? Can customers get it cheaper elsewhere?
  10. Do I understand what the rest of the product team thinks is good about the product? Is it consistent with my own view?

Overall takeaways

Winning products come from the deep understanding of the user's needs combined with an equally deep understanding of what's just now possible.

We tend to want to think of our users as we thing of ourselves and our friends. However, the target market very likely has quite different values, priorities, perceptions, tolerances, experiences and technical understandings.

Prototype and test with users before starting engineering on larger initiatives.

Prototypes should be required in PRDs.

Start doing rapid response phases.

Conducting user testing with our competitors' products can give us insight into a competitive edge.

Many times customer != user.

Measure to gain better visibility into our progress.