When I started as a Product Manager last year, I knew I had a lot to learn. I scoured through the internet, reading everything I could find on Product Management and how to succeed starting out as a non-technical PM. I have compiled a list of some of the most useful things I have read, partially so that I can revisit them myself from time-to-time.
Some of these articles are not strictly product-related—many of them involve design, project management, and elements of software development. The PM role varies greatly between companies, and often involves stepping in to fill whatever necessary gaps exist in order to ship a successful product.
Product
Good product managers crisply define the target, the “what” (as opposed to the how) and manage the delivery of the “what.”
Good Product Manager / Bad Product Manager – A note by Ben Horowitz that is worth a re-read every few months.
believe great taste can be developed but not in a linear manner that is predictable or time bound. The best, and perhaps only way, to develop great taste is to be interdisciplinary and to gather a large variety of life experiences to draw upon. This is why Steve Jobs’ focus on the intersection of technology and liberal arts has always made a lot of sense to me.
The Three Skills of a Great PM – Some core skills of an effective Product Manager, distilled into 3 semi-quantified “rates”
Product management may be the one job that the organization would get along fine without (at least for a good while). Without engineers, nothing would get built. Without sales people, nothing is sold. Without designers, the product looks like crap. But in a world without PMs, everyone simply fills in the gap and goes on with their lives. It’s important to remember that – as a PM, you’re expendable. Now, in the long run great product management usually makes the difference between winning and losing, but you have to prove it.
How to Hire a Product Manager – An essay by Ken Norton from Google Ventures. Although it is obstensibly written for people looking to hire a PM, it gives a great outlook into the role for someone trying to get hired.
Design
There is your product and then there is the experience someone has using your product. It’s easy to see the difference from afar, but to the person using your product they are one in the same. This cannot be understated. Every interaction with your product/service/company matters and becomes part of the product experience.
The experience is the product – Joshua Porter on the inseparability of the product itself and the experience that surrounds it.
Book review: The Design of Everyday Things – A good summary of one of the classic books on Design by Don Norman. This summary convinced me to read the whole book.
The single easiest way to see things through the eyes of your new user is to simply watch your user interacting with your product for the first time and talk to her about the experience. Don’t try to do this without help from your users. You know way too much.
You Know Too Much – Laura Klein on why it is so difficult to keep use conceptual models in our head, and why it is essential to watch users interacting with our product.
Learning about your customer is the single most important part of your startup. If you’re outsourcing that to a person who isn’t directly responsible for making critical product decisions, then you are making a horrible mistake.
Startups Shouldn’t Hire User Researchers – Laura Klein on why user research should be a responsibility of PMs
The fact is, understanding what your users like and don’t like about your product doesn’t mean giving up on your vision. You don’t have to make every single change suggested by your users. You don’t have to sacrifice a coherent design to the whims of a focus group.
6 Stupid Excuses for Not Getting Feedback – There is a good chance that you recognize at least one of these excuses.
One of the main reasons I like the thinking aloud method of user testing is that it gives us insights into a user’s mental model. When users verbalize what they think, believe, and predict while they use your design, you can piece together much of their mental model.
Mental Models – Jakob Nielsen explains how good design needs to consider the mental models that users carry while interacting with your product. Good design is always a moving target.
Execution / Shipping
Ideas are just a multiplier of execution – People generally overestimate the value of ideas and strategy, while underestimating the critical importance of execution. Business students in case study discussions will spend 70 minutes fiercely debating high-level strategic issues, then round off the final 10 minutes on operations and execution by saying “Then we’ll hire an engineering team and build out the product.”
There is no later for your customers. The only thing that matters is what they’re using right now. They don’t give a shit about your roadmap, your brilliant feature pipeline, or your vision of a better future. They’re trying to get work done right now and they only know what you’ve already delivered. So build a discipline around your launches, knowing that your temporary, let’s get this out quickly and iterate later release is the current reality for your customers. Build up your attention to detail and force yourself to treat every launch like it is your final launch. Imagine that you’ll never be able to deploy something after this…have you done your best work?
There is no later for your customers – “Just Ship It” is not an excuse to release a sub-par, unfinished product to the world. The concept of Minimum Viable Product is also wrongly applied in this regard as an excuse to ship something half-baked.
This is one of the reasons why B2B applications often get away with being so awful and hard to use. If a product helps me do my job better and makes me more money, it’s solving a big problem for me. I’ll put up with a few missing features or a less than stellar experience.
How Bad Can I Make My Product? — A good litmus test for determining approximately how much you should be sacrificing release quality and polish for speed.
So what makes an idea guy an idea guy? Usually it’s the simple fact that they don’t have any other skills to bring to the startup.
5 Reasons you don’t want to partner with an “Idea Guy” – People unfamiliar with the industry often equate Product to being the Idea Guy. Ensure that you do not fall into this trap as a non-technical PM—always focus on delivering tangible value through analytics, testing, and pursuing a deep understanding of the customer.
Software Development
The work of implementing a feature initially is often a tiny fraction of the work to support that feature over the lifetime of a product, and yes, we can “just” code any logic someone dreams up. What might take two weeks right now adds a marginal cost to every engineering project we’ll take on in this product in the future. In fact, I’d argue that the initial time spent implementing a feature is one of the least interesting data points to consider when weighing the cost and benefit of a feature.
The One Cost Engineers and Product Managers Don’t Consider – Without acutely understanding the compounding effect of complexity costs on engineering resources, the product organization can find it increasingly difficult to ship new features.
The key is to understand that the root cause of all this grief about commitments is when these commitments are made. They are made too early. They are made before we know if we can actually deliver on this obligation, and even more important, if what we deliver will actually solve the problem for the customer.
Managing Commitments in an Agile Team – Making meaningful estimates on software development projects is a long-standing problem that has had entire books written about it. Understand how you can manage expectations with stakeholders and work with engineering to avoid the all-to0-typical disappointments of time and cost overruns on poorly made estimates.
comments powered by Disqus