Product features were the first thing I had to come to grips with when I became a product manager. One of my first tasks was to write requirements for product features.
I worked in large teams delivering large and complex products, so as a newbie, I was asked to write up how certain parts of the product would function. It required strong analytical skills and great written communication, as well as a knack for collaborating with those around me to get it right. It was highly involved work, and I would admire the neatness and structured beauty of what I had created. Later, I’d be utterly infuriated that the feature never turned out like that.
This type of detailed work is a great place to start as a PM and a skill set to hone throughout your product management career. However, writing feature requirements is only a small part of the whole product management process, just as a feature is only a small part of the product.
To be a great PM, you need to understand what a feature is, how it fits into the product development hierarchy, and how to manage it through the product development process.
Here’s what I wish I had been told when I started.
A product feature is a thing your product does, and that thing should help solve the overall problem the product is trying to solve.
Take Google, for example, whose mission is to organize the world’s information and make it universally accessible and useful. Search is a product that allows you to easily find information you are looking for, and the search bar — the product feature — allows you to enter the term you are searching for via text input.
This high-profile example shows excellent alignment from vision to product feature with a unified goal of helping to make information universally accessible. It also demonstrates that a product feature should be both tangible and easy to understand.
Have you ever created a product feature with love, care and attention, only to release it to the world and watch it wither and die? When you look back on that experience, I’ll bet you didn’t fully understand the context in which that product feature would operate for users.
Context is critical when you’re developing the feature, too. Understanding where the product feature sits in the product development hierarchy will help you create better features and manage them in the product lifecycle.
Every great product starts with a problem to solve. At the top of the hierarchy is the product vision, from which you derive the strategy that you articulate in your product roadmap. On your roadmap, you should have the themes that you will explore to take you closer to your vision.
Let’s work through an example. Let’s imagine your product vision is to simplify the Friday night takeaway decision by bringing all options into one place. Your strategy is to start with takeaway-only restaurants and you have a beta version of your product out. You are finding that users are struggling with the checkout process and baskets are being abandoned. So you introduce a theme on the roadmap to optimize checkout.
Great! So what next? Well, you need to know more about why people are struggling to check out. Using data and talking to customers should uncover some potential reasons.
Let’s say, for example, that customers are finding it a pain to go get their card details and are abandoning their purchase. Let’s say they’re going to an incumbent competitor because their card details are saved on that platform.
In response, you decide to introduce three features: Apple Pay, the ability to scan a card to autofill the payment details, and the ability to save card details in the account. All of these features are designed to make getting that Friday night takeaway easier.
You will notice that, with the above example, I did not lead with, “Apply pay is awesome, we need to add it!” However, this type of conversation occurs every day among product teams. Understandably so — after all, product features are easier to explain and communicate than a problem.
Sometimes, it seems obvious that some feature is just the thing the product is missing. However, only through rigorous understanding of the problem you’re aiming to solve can you truly be sure — or at least sure enough to develop it — that the feature will be an asset to your user.
There’s never enough time in the day to build all the amazing features product teams want to deliver. So how do you prioritize product features?
If you approach this challenge by asking yourself which feature is the best one, you won’t get very far. Features are the outcome of a process that starts with the customer problem.
Let’s go back to our previous example: How might you prioritize the features that aim to optimize checkout? Which features would best address the problem?
Apple Pay is probably an easier journey than scanning cards, but that will only work on Apple devices. If the majority of your customers are not using an Apple device, this won’t be the best way to solve the problem.
By approaching it from the viewpoint of the problem, you get a more robust conversation about the reason behind what you are doing, and this can drive better decisions. Talking about trade-offs from the customer’s perspective is far easier than exchanging personal opinions that will inevitably be influenced by bias.
The piece I wish I had understood earlier in my career is the amount of work that goes into understanding what is the best thing to build — that, prior to my task of writing up the feature definition, a whole host of work had gone into understanding the problem and trying out potential solutions. Today, I have a growing appreciation for the discipline and skill required to write great product definitions.
Details are important. Ever had a product where you get lost in a loop of error messages? How infuriating!
When it comes to communicating with your engineers and designers about how you expect a feature to work, don’t forget to go over what happens when the user doesn’t do what you thought they would do. Collaboration is key, and the more detail you go into, the more you will pull out before you build.
However, the cost of this is time, so it needs to be a careful balance. It might be worthwhile to ship features quickly and then go back and fix things later. It depends entirely on your product and what your users will accept.
Put simply, a product feature is a thing that your product does. However, if you start by thinking about features, you are going to miss a whole host of things that can make your features successful.
By working down from your product vision and ensuring you keep focusing on the problem you are solving, you will end up with better and more valuable features. Once you really understand the problem your product is trying to solve, everything else falls into place.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
This article covers insights for overcoming common challenges, as well as ways to embrace innovative ecommerce strategies.
Dipto Chakravarty, Chief Product Officer at Cloudera, talks about how it takes rigor to design complex technology and user experiences.
As an alternative, this article outlines a case against MVPs, drawing on my own personal experience in the realm of product management.
No product team starts out trying to harm users. However, harm still happens, and often not from one big decision.
Learn more →
