Product Management

A few years ago I developed EFQ, a prioritization framework for deciding what to build. It stands for Effort, Frequency, Quality risk. I’ve been applying it to automation and agentic builds. It translates directly. What is EFQ? EFQ is modeled on the ICE scoring approach where you score ideas to quantitatively determine which to pursue. The difference: all three factors come from the customer’s perspective, not yours. Effort — How much time does this task take the customer? Minutes = 1, hours = 3, a full day = 5. ...

We’re all familiar with the popularly adopted RICE framework which teams, product managers use to prioritize quarterly and annual roadmaps. While a handy and easy to understand tool the application of the tool often misses key contextual aspects and the required depth to make high quality prioritization decisions. I’ll call out a few gaps that might arise from RICE: #1 Time horizons Impact should be framed in terms of time horizons. Initiatives can take time to mature, show sustained and long lasting benefits. Imagine an initiative that requires improvements to retention, loyalty or a new business line. Keeping an artificially short time frame can over emphasize the value from incremental improvements because those could potentially materialize impact sooner. ...

As a product owner deciding what to do or not to do for your product can be tricky. Most often the number of opportunities in front of you are more than what you, your team and company can focus on. Between the qualitative and quantitative data from your customers, competitors, stakeholders and your own team this decision making can become over whelming. Getting to key focus areas is definitely an exercise that involves both art (intuition) and science (frameworks). Intuition as I define it is judgement, insight borne out of observation and possibly experience. There are probably better words to describe intuition but I’ll leave that for a different post. Let’s talk about frameworks… ...

Most of us have either heard of or used A/B testing which is a widely employed technique across industries from medicine to software development to measure one version of the product against the other. It’s a method to validate if your beliefs about a new feature or an improvement are actually true and if so to what extent. The reason I’m writing this is two-fold — to collect information about the statistics and math behind the process in one place and also solidify my own understanding of these concepts. I am by no means a statistics, probability or math expert so happy to hear feedback or corrections. ...

Often times during interviews and social conversations I get asked by people what a day in the life of a Product Manager looks like. The first time someone asked me that I was actually taken aback on how difficult it was to answer that question. Any given Monday, Tuesday, Wednesday is different from the day before and the Thursday will be very different. Perhaps it’s the very nature of being at a startup but the variability in the type of work is what personally excites me. ...