5 Product Management Tenets

Good foundation is important.

Product development is hard. It is a constant challenge to stay on track and focus on the right problems to solve. Often, discussions about features, roadmaps, users tend to get convoluted, easily get off track and result in long, unproductive meetings.

Having a set of tenets can help setup a good foundation for product development process. I have found that these 5 tenets, if followed, can yield the right kind of thinking around any product related discussions and guide product teams to better outcomes. Some of these are dependent on the culture of your company, so you can use these tenets to evaluate the current state of your company and how it perceives thinking around product management and development.

1. Chase the Dream > Chase Competition

Too often I see product managers spending hours researching competitors, looking at their features, and trying to see what could be added to their product to create feature parity. Instead, that energy could be spent focusing on your own customers and solving their problems. Of course, you don’t want to completely ignore how your industry is evolving, but ultimately your customers have problems to be solved, while your competition might be focusing on the wrong things. Be the leader that everyone else is chasing and trying to copy.

2. Outcomes > Outputs

People naturally gravitate towards talking about features first. It usually starts with”lets build X so we can have Y”, without ever touching upon the what problem is being solved, for whom or exploring things assumed to be true. If you don’t first agree as a team on outcomes you wish to see, you’ll end up in endless argumentative and opinionated discussions around what features to build, which lead to very little productive product talk.

3. Simplicity > Complexity

It’s important to always simplify, then simplify even more. Even the simplest features can quickly become complex because someone on the team might think of an edge case or start asking “what if customer wanted to export the file, we should add that feature”, quickly increasing feature complexity. Building an MVProduct or MVFeature is never an arbitrary process, it is a scoping exercise. If you focus on the right scope around the hypothesis you are trying to test, feature simplicity will come through naturally. If there is pushback that the feature is too “basic” and no one will use it, remind them that the world doesn’t end after the first release, and it can be added later if customer feedback confirms there is a real need.

4. Learning > Assuming

If you position your product features as experiments, you are communicating to others that your goal is to maximize learning, not assume something you want to validate or build is going to work. It is also a powerful tool to use when someone suggests building something that may take many months. Asking “what needs to be true for that feature to be successful?” will focus the discussion around all of the risks and assumptions that are naturally built into every idea. Then, agree to limit the scope of the feature by going only after the riskiest assumption first and building just enough to learn if the assumption is true or not.

5. Measuring > Guessing

Without data, you can’t determine how successful you are. This tenet is a reminder to ensure you are measuring outcomes of your product development efforts, as well as to bring data into discussions to focus on facts, not opinions. In words of W. Edwards Deming, “In God we trust; all others bring data”.

Originally published at https://www.linkedin.com on June 23, 2017.