One of the biggest mistakes I see PMs, and people in general, make is their bias towards action. I don’t come to my job with the protestant work ethic and preference for action in every possible situation. Instead, I find much of my thinking about labor/effort better reflected in the Dao De Jing. Among it’s messages is to act as naturally as possible, to spend effort on identifying the flow and going with it, rather than activity for its own sake. This is sometimes boiled dow to the translation “do not doing”. In product management, I apply this to mean “sometimes it’s okay to CHOOSE not to do something as the best strategy”.
Resist the temptation to view work and activity as a valuable end, in-and-of itself, or as the solution to all problems.
This kind of “inactivity by choice” can be the right strategy in many situations, here are three examples:
Sometimes don’t build, repackage
Often, in software companies the temptation is to keep building new things. There’s a genuine need to deliver new features and updates every cycle for sales and marketing. And we’re paying a lot of engineers, we better keep them busy with interesting work! But I have had some of my biggest successes not with new things, but with old things applied and packaged differently. Often, the desire to do something new is because the existing product is not gaining the market or stakeholder acceptance expected. But if you do your research and listen to what users are saying, you may already have the solution with very little technical work. Instead of 6 months developing a new product, a change in interface emphasis and new marketing story may sell just as well.
don’t overreact to Analytics Noise
I worked in a very data driven organization with a hard driving (but quite effective) chief executive. The PMs and C-levels lived in fear of the email with a screenshot or link to a dashboard: “this number was down, do we know why?”. Many of these were valid queries, and they occasionally uncovered genuine issues. But more often than not, it was an unexplainable short blip, analytics bug, or most often, just a misunderstanding somewhere. And this chief executive was a genius (really). Most of us lesser mortals have an even lower “spot-a-real-problem” hit rate. That’s not to say you shouldn’t care or monitor your numbers (quite the opposite) but also learn how much noise and error exists in your context, and learn to triage these numerical mysteries as you might with bugs. Develop a methodology and intuition to know when to take action, and when to do nothing.
sometimes pass on an opportunity
In dealing with sales, or functions driven by month/quarter bound commissions or bonuses, there is a constant pressure to deliver something for a client or timeframe that does not account for your team’s reality. As with a marathon, just because you can run a 6 minute mile, doesn’t mean you should, if you want to finish the rest of the race. Asking the team to work nights and weekends better pay off, at least more often than not. Rearranging your roadmap for a marquee client can work, but it can also become a golden goose chase, giving the team whiplash and undermining any strategic thinking or product theories. Too many start-ups have been destroyed by taking on too much business or chasing a series of mega-opportunities before they were ready. Sometimes the best answer to inbound business is not “YES!”, but “not yet, but let’s talk”. Don’t go bankrupt “screening” your customers, or rigidly maintaining your scope in the face of product failure, but, also, be willing to be the leader at the table that says, “no, let’s not put in this in our sales proposal”. (Of course, a compelling “and here’s why…” should follow).