Software development is a dizzying terrain of new terms and technologies, so when you are innovating it can be easy to get overwhelmed with all the possibilities. While setting priorities is a cinch with tools like Shortcut in your arsenal, it is important to also be mindful of common product management pitfalls that will challenge the success of your new efforts.
In this article, we outline a few common product management mistakes and how to avoid them so that your great ideas have their best chance to succeed in our rapidly-changing market.
If you create your entire product in a silo, without getting feedback from external sources (especially your intended customers/users), you’re that much more likely to wind up creating something nobody wants.
The way to get around this potential pitfall is simple: collect feedback as often as possible in the process. Not just from other people internally, but from the people who would actually be using your product in their day-to-day lives.
And then, of course, you need to listen to that feedback and let it inform your product development accordingly — even when it hurts your ego a little.
When you’re creating something new, it’s easy to get excited about all the possibilities. You can see what you want the product to look like in a year or three or five, and you want to bring that vision into reality now.
The problem is that when you start the product development cycle by cramming in every single feature you can think of, you’re likely to:
Instead, you want to focus in on one differentiating factor (which can actually be a lack of features — “instead of trying to do everything under the sun, we do these two things and we do them perfectly”) and the 2–3 features that complement your differentiating factor.
At this point, pretty much everyone is familiar with the lean startup model and the concept of a minimum viable product that goes with it.
The idea is that instead of debuting a fully-developed product (with all of the time/energy/cost that goes into it) to potentially find out nobody wants it, you create the smallest version of that product possible, to test the demand for that product.
Then, you work on fully developing the product based on user feedback
The problem is that too many people focus on the “minimum” part of the MVP instead of the “viable” part. This can result in apps that are under-designed/developed to the point of being unusable, or someone throwing up a landing page with an email sign-up on it as their sole validation method.
That’s not to say that email collection can’t be part of the MVP process — but a landing page does not an MVP make. As Jim Brikman puts it:
An MVP is a process that you repeat over and over again: Identify your riskiest assumption, find the smallest possible experiment to test that assumption, and use the results of the experiment to course correct.
Along with avoiding getting user feedback, many people put off testing until the last possible moment. It’s true that you don’t need to be running A/B tests when you only have ten users — the data set is way too small — but it’s also true that you should implement it as early as realistically possible.
Creating a company/product culture of testing everything and going with the data, instead of office politics or one person’s whims, is important and should be done as early as possible.
Outside of testing things in-app, you should also be testing your site and landing pages.
This can help you get more bang for your buck on any advertising or marketing budget you have (by optimizing the landing pages to get more conversions), but it can also help guide your product development.
If you’re emphasizing Feature Set A on one page and Feature Set B on another page, and one of those pages converts to users at a much higher rate than the others, that’s valuable customer feedback that you can get without ever doing a user interview.
Everyone prepares for failure, even if they don’t want it to happen — but do you have a success plan?
Having a sudden influx of users can cause scaling issues on every front: inability to keep up with customer support or onboarding new users, your app crashing under the amount of new users, and so on.
You can be faced with more costs in running your business, without necessarily having the revenue from those new customers yet (depending on how long your free trial period is, if you offer one).
When you’re doing your product planning, make sure that you have plans for what to do if you wind up with more customers than expected and can’t scale at a slow/normal pace.