In our last post, we looked into the main differences between project and product managers. This time, we’ve composed guidelines for starting as a Product Manager as proposed by M. Cagan’s “Inspired – How to create products customers love”. The two key areas of focus will be People and Process. Here is what you need to know about what key people you need in your team and how to build a product.
What M. Cagan says about Product Managers, and what I totally agree with, is that PMs are amongst the most important positions in any high-tech company. They act as CEOs of the products, who are responsible for building a great team and for the overall product strategy. What is the typical team structure necessary to build a product? It varies, of course, case by case.
Typically, Product Manager works side by side with the following team members:
User Experience (UX) Designer or Interaction (UI) Designer. The designer has generally one mission – to make software both usable (users can figure out how to use it) and valuable (users actually want to use it).
Project Manager – they take care of project scheduling and tracking. This role is sometimes performed engineering managers, or product managers, depending on the structure of the team.
Engineer(s) – they actually build a product.
The following comparison clarifies the distinction:
Product management vs Engineering – Building the Right Product versus building the Product Right
Product Marketeer(s) – they are responsible for spreading a word and telling the world about the product.
The process is all about asking the right questions and taking the right actions. Where to start?
1. Product Opportunity Assessment
In order to validate the product idea, and now if it’s worth a try, I would start with the Product Opportunity Assessment. It helps to save time and money on poor opportunities. And for the good opportunities, it helps to focus on requirements for the successful product. M. Cagan listed these fundamental questions to do the opportunity assessment:
- Exactly what problem will this solve? (value proposition)
- For whom do we solve that problem? (target market)
- How big is the opportunity? (market size)
- How will we measure success? (metrics/revenue strategy)
- What alternatives are out there now? (competitive landscape)
- Why are we best suited to pursue this? (our differentiator)
- 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)
The opportunity assessment should just discuss the problem to be solved, not the particular solution you may have in mind. Asking these questions opens up an opportunity to better understand the problem.
2. Product Discovery
Figuring out what to build, discovering whether there are real users out there. In other words, you need to identify the market and validate the idea with your customers. Be open, welcome and explore new ideas, talk with scores of users and customers, learn how you can apply new technologies, flesh out your product concepts and test them out, and spend a lot of time thinking about the overall product direction, both immediate and longer term.;
3. Product Principles
It’s about deciding what is important to you—and what is incidental—and deciding what is strategic and fundamental, and what is simply tactical and temporary. Product principles are not a list of features and, in fact, are not tied to any one product incarnation. In this sense, they are most aligned with a product strategy for an entire product line, or with a company mission statement for a startup. A good set of principles serves as the basis or foundation for inspiring product features.
4. The Product Council
To get the key stakeholders and decision makers together to make timely and informed product decisions.
5. Charter User Programs
Getting deep insight into target customers, and having great reference customers at launch—is to use a charter user program (also known as a Customer Advisory Board, Customer Council, or Voice of the Customer). Make a goal to end with at least six happy, live, referenceable customers from your target market. That means you’ll probably need to start with 8-10. So your job is to recruit these customers right at the start of your project. You’re looking for customers in your target market who would make great references.
6. Market Research
7. Personas (aka user profile)
A technique for identifying and understanding the different types of people who will be using your product. The creation of personas should be a collaboration between the product manager and interaction designer and—if you are lucky enough to have them—your user research team.
8. Reinventing the product spec R.I.P. PRD
Product Requirements/PRDs, Market Requirements/MRDs, Business Requirements/BRDs, Functional Specs/FS, and more are rarely useful, too long, no one reads them. More and more often, these specs are being replaced by high-fidelity prototypes. The term “high-fidelity” refers to the fact that this should be a realistic representation of the proposed user experience. With the tools available today, like proto.io, justinmind.com, and many others, it is now so quick, easy, and inexpensive to create a high-fidelity prototype for most products that there is no reason not to do so. And a working prototype can be tested by target users!
There are some aspects that cannot be represented in a prototype, such as business logic (e.g. shipping charges), the release requirements (e.g. scalability, performance) or platform delivery requirements (e.g. browser versions to be supported). Use cases is another supplementary piece of material used to describe the most important flows through the product. Although this information cannot be embedded in the prototype yet it should enhance the high fidelity prototype.
9. Design vs. Implementation
Define the user experience before proceeding to build.
The old waterfall model of a product manager doing “requirements” and handing that off to interaction designers that do “design” has become obsolete. It usually takes longer and the result is less reliable. Implementation and testing should be performed in concert. That said, one thing that many teams try to do in parallel—but should not—is user experience design and implementation. Once implementation begins, it becomes increasingly difficult to make the fundamental changes that will likely be necessary as you work through your user experience design ideas. The key is that the user experience design needs to happen before the implementation begins. The requirements and design happen together, and then implementation and test can happen together. For Agile teams, the product manager and user experience designers use the “sprint zero” concept to stay a step or two ahead of the engineers.
10. Minimal Product
The first job to do for a product manager is, together with a designer, to build a high-fidelity prototype with the minimal functionality necessary to meet the business objectives and with a user experience that users can figure out how to use—and actually, want to use. Only minimal functionality is required in order to minimize the implementation time and user complexity. The minimal product has to be validated by performing such testings as Feasibility, Usability and Value Testing. Testing your ideas with real users is probably the most important activity of a product manager. It shows whether users can easily to the tasks they need to do and whether they actually value the product.
11. Gentle Deployment
12. Rapid Response