Product Management References
4 min read

Product Management References

Top level metrics

This post by Itamar Gilad walks through why you should choose a metric that represents delivered value, and another that represents captured value to help set strategic goals.

I like thinking about Slack as an example. I remember first setting it up for Blispay in 2015. It was so much better than Skype and Hipchat. Cross-device support was magical and channels were much better than the endless groups you had to create in Skype. Anyway, early on, I think their north star was 'paid users.' It evolved over time to be 'succcessful teams,' which was when 5 people in an org exchanged messages because at that point, it was highly likely they'd be hooked because of the value they are starting to gain. 'Successful teams' represented value being delivered to customers, while business KPIs like revenue measured value that the business was capturing as a result.

Product metrics

See full post here: Product Analytics Overview


See this seminal presentation on startup metrics for pirates by Dave McClure back in 2007. I think this or some version of it adapted to your specific organization is the single simplest and most important framework for goal setting and alignment.

Three feature buckets

Read more about this simple framework from Adam Nash.

Impact x Effort prioritization

5 Why's

Simple, effective way to get to the truth.

  1. Why?
  2. Why?
  3. Why?
  4. Why?
  5. Why?

Methods to stay customer-focused

  • Rolling or quarterly NPS surveys
  • Join compliance-driven customer/ops calibration calls
  • Peruse online forums
  • VIP program for discovery and initial product roll outs and feature toggling
  • Maintain close relationships and frequent touch points with teams in your org who interact with prospective or existing customers on a daily basis (sales, account management, customer ops)
  • Try to be a user yourself, as much as possible. Work on products you can identify with

See full post here: Unlocking Customer Insights: Qualitative Techniques for Product Managers

Product announcements, memos, and working backwards

I wrote Product Announcement Playbook back in 2019 to provide a real-life example of working backwards from defining a vision with goals (via an internal press-release style post), defining deliverables, crafting a roadmap, developing, and providing periodic updates to stakeholders. In a way, it appears quite waterfall (sorry agile nazis). But in actuality, it's much more flexible in that requirements and deliverables aren't set in stone. The biggest benefit is that the team has a clear vision of what they're working towards, and a potential path of getting there. It's is very product development focused. Some orgs need this for certain types of products. It's a bit of a mashup between Amazons Working Backwards Internal Press Release (PRFAQ), Ripplings Memo (Strategy Doc), requirements gathering and understanding, and stakeholder management.

Always cringy to revisit old work but figured I'd share the one below. I drafted a bunch of these at the end of 2014, the month before we officially started Blispay so we could hit the ground running with product development right out the gate.

PRD / product spec

Product development design doc

Decision-making consensus

Read more about Gokul Rajaram's SPADE framework.


When in doubt, draw. Draw on paper, on a whiteboard, on a sticky note, on Miro, on Slides, anywhere. Just draw. Some examples I shared back in 2019 from projects I worked on over the years. Nothing helps facilitate a product conversation as well as imagery. And nothing quite conveys requirements as well as them either.


Putting it all together

Theoretically, a lot of product work should involve some of these components. But reality is... messier. At the end of the day, you need to be pragmatic. Product matters more than process. And I don't think a lot of this is helpful or necessary at the super early-stages of a startup.

During the earliest stages, all that really matters is building something people actually want, distributing value to them, and ultimately having a way to capture value.