The ultimate guide to Product Management

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:

  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)
  9. What factors are critical to success? (solution requirements)
  10. 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.

If you are having real trouble recruiting charter users and customers, then it’s very likely you are chasing a problem that isn’t that important, and you will probably have a very hard time selling this product. This is one of the very first reality checks to make sure you are spending your time on something worthwhile. If customers aren’t interested in this problem, you may want to rethink your plans. 

6. Market Research

There are plenty ways of doing a market research. Just to name a few:
Customer surveys – easy and powerful. Combined with techniques such as conjoint analysis (to help users rank order their preferences), customer surveys are so easy and so inexpensive, that they’re a must-do for any product.
Site analytics. If your product is a Web site, there are terrific tools out there for understanding how your users are using it. You’ll have to do a little work to make sure your site is instrumented appropriately, but it’s well worth it.
Data mining. You’ll collect data from many sources, such as the site analytics I’ve mentioned above, billing and user account information, and your own product’s data. 
Site visits. There is no real substitute for visiting with your users in their native habitat—home, office, mall—wherever they will use your product.
Personas. It’s essential to realize that there is no single “user” and your job is to deeply understand the major types of users out there—those who are your current customers, and those you want to have in the future.
Usability testing. Essentially, it’s a way to see through their eyes while they use your product—you can gauge enthusiasm or frustration, and watch actions (and not just words).
Competitive analysis. Every product has at least some things that the product does well, and it’s your job to find these things. 

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,, 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

Help Prevent User Abuse. User abuse happens when you unnecessarily and unintentionally mistreat your users by releasing changes to the user community that they don’t appreciate. As a general rule, users don’t like change. They want the software to be great, but most people aren’t excited about taking the time to learn a new way to do something they can already do. In the spirit of minimizing the disruption caused by change, there are several techniques that can be useful in deploying changes gently. One solution is communication of upcoming changes through means such as newsletters, onsite education, and tutorials. But remember that many people don’t read what you write, so this technique can only take you so far. Second, if there is any question about the new version of your product working properly—either due to reliability issues, or scale, or performance—then you need to redouble your QA efforts to ensure that you won’t have to rollback your updates, which compounds community angst significantly. Third, if the change is significant, it may be important to contain the risk by pursuing some form of gentle deployments such as parallel, or incremental deployment. 

12. Rapid Response

More often than not, the product team that has been marshaled to build and launch the product quickly after a launch is put on the next project coming along. This, however, may cost a lot of money, as the moment after the product launch has the greatest opportunity for learning and correcting whatever could be improved. This is where a project management and product development processes fail and it can be corrected simply by slightly extending the project to incorporate this critical phase. No phase of the process will provide a better ROI than this one, so the change is not a difficult pitch to management.