Move your Product Management career forward

Features that aren’t used cost money to support. Let's discover when should you kill a feature, what to consider when you do it and how to communicate it to your users.

Tis the season for annual planning. I had a realization recently. From a theoretical standpoint, a team can avoid the overhead and waste of annual planning. It isn’t difficult. How? To quote Jez Humble, “If it hurts, do it more frequently, and bring the pain forward.” You must plan, align, and calibrate more frequently. Teams that do this 1) limit planning inventory, 2) resist premature convergence, 3) research at the right time, 4) reduce sunk-cost bias, and 5) stay more strategically aligned.

Watch this clip for the answer

A couple of tweets that explain the importance of sound customer account selection

One of the primary benefits of working in a product trio is we reduce the hand-offs between functional roles. There’s only one problem. Products aren’t built by trios. We typically have additional engineers, sometimes a second designer, maybe a product owner, a scrum master, and any number of additional roles depending on the organizational context. How do we avoid hands-offs between the product trio who is leading discovery and the rest of the team?

The ICED theory presents a mental model to help address the challenges faced by infrequent products and facilitates the crafting of a growth-oriented approach.

I wanted to organize my thoughts on how to approach different aspects of growth for startups and writing a guide for others seemed like the best way to do that. It's based on my experience building Statuspage.io, and is also influenced by (read: liberally stolen!) other guides, tweets, conversations, etc. but 🤷🏻‍♂️.

Common sins and how to reverse them

I often get questions from founders about how they should think about the “technical moat” of what they’re building, or from potential employees about our technical moat at Heap. If you have a successful product, what’s to stop someone else from building it? Technical moats exist, but they rarely take the form people expect them to take.

I’ve heard of many startups that have been working on their product for 6 or 12 months, but have not yet calculated what the prices for that product will be. If I were to be diplomatic, I would say it’s not an optimal situation to be in for the founders of those startups (or their team members, or their investors). If I were to be honest and direct, I would say those founders are being reckless.