Top 5 Mistakes Product Managers Make (and how to avoid them)
Building a product is a complicated process, and it is easy to get overwhelmed in the process of dealing with requirements, users, use cases, UI/UX, launch and marketing, feedback and iteration and more. As you navigate this maze of building and launching products, beware the 5 common mistakes that Product Managers inadvertently make, which can result in your product going way off track.
1. What users want vs What users need
When you're building a product from the ground up, you (hopefully) have a set of target users in mind. You have a good sense of what these user's problems are and what would make their lives easier. So you're building a product that solves a user pain point. But before you jump in and unleash your solution onto the users, pause for a minute and ask yourself if you're building what users want or what users need.
Many times, Product managers directly ask users what they want and base their product on this input. While talking to users is a great thing, you need to be aware of two limitations of simply building what users say they want.
Firstly, Users don't know what they want. They're stuck in the middle of the problem, and it is hard for someone right in the middle of a problem to see what the best solution might be. It might need some "out of the box" thinking to understand the most optimal solution, something your users might not think of because they're so focused on the problem.
Secondly, User's don't know what's possible. Users have a rough idea of what solution might work for them, but it is the Product Manager's job to search the realm of possibility to see what solutions might fit. Users are not aware of the latest technological developments, or the changing landscape of what a cloud service can do, for example. The biggest value a product manager can bring is to look beyond the problem space to see if other solutions could work here.
2. Yourself vs Your Customer
When it comes to defining what a product will do, the devil is always in the details. You may have a very good big-picture understanding of the problem and the solution, but when you're sitting down and designing the individual features, lots of small details are un-answered. Do users want to view a list of products by price by default or by popularity? Do users search for a product in the search bar or go through the categories to reach what they're looking for.
When confronted with these questions, it is quite tempting to simply ask "What would I do?", and solve the problem. The issue with this approach is that you are not thinking like a user, and what a Product Manager would do is not at all what an end user will do. You're very familiar with the product, your users are not. You already understand the path to the solution, your users don't. You're likely 100% focused on the task at hand right now, your users may not be.
You must resist the temptation to think your users will do what you will do. You need to actually find out what your users do, and react to that. You can either observe your users as they use the product to understand how they use it, or better still, use analytics and data to measure how users interact with your product, and make decisions on those.
3. Features vs Value
Quick: If a new version of a product adds several new features, is it adding more value to its users?
If your answer was "more features" = "more value", then think again. Adding more features may in fact be taking away from your product and reducing its overall value to users. More features almost always means more complexity, and more complexity is usually a very bad. "Feature bloat" is an infamous software phenomenon where a product bloats up to unusable sizes. Apple's iTunes is my favorite example of a product that's been ruined by adding additional features. Instead of being a simple music-management software, it is a multi-media store, a music player, an advertising platform, a social network and a iDevice management console.
This problem can be fatal if your product is based on the freemium model. If your paid version has too many features, users may actually prefer the "lite" or free version, completely killing your revenue stream.
4. Complete Product vs Sellable Product
All software has bugs. From Windows to the software on board spacecrafts, all of them have bugs. The corollary is that no software can ever be perfect. This means that it is useless to hold off your product launch until your product is "perfect". You could end up waiting for a long time, and your company will time-out before you ever release the software.
The threshold for launching your product should be when it reaches a "sellable" state. That is, people are willing to use it (or pay for it, if you're software is paid). All users have a certain tolerance for bugs, as long as you have a graceful failure mode. There's a saying at Facebook, apparently - Done is better than perfect!
Don't hold out for some mythical quality bar before launching your product. It is always better to get your product out early and get early feedback and iterate.
5. Launching vs Sustaining
Getting a product built and launched is only half of the Product Manager's job. Making it successful, getting it in front of millions of users and driving adoption are the key activities that are still pending once the product is out of the door. The focus shifts from internal development to external feedback after launch, and the product teams must continue to be engaged even after the product is launched.
There will be a constant stream of feature requests and bug fixes, but more importantly, you need to ensure the direction of the product is right, and that you are responding to the landscape shifts in the industry. How does cloud-computing and big-data analytics affect your product? What about mobile computing? Some of these trends are already here, but have you thought about what will come next?
Wearable computers? Software with 3-D interfaces? Is your product strategy ready to handle these shifts?
