Open Intro

Product jobs are funny.

You'd be offended if (rather when) anyone mixed up their terminology and called you a Project Manager.

Yet, in many ways, there's a bit of the job that's classic PMBOK project management.

You'd be on your toes if someone asks if it's like being a Business Analyst in the old days. No! It's more than that. You're in the trenches, but you're also strategic, you're full stack.

You cringe when someone calls you the CEO of the product. "If only", you think. "I get to manage the CEO so the team isn't constantly swerving left and right getting derailed."

You're sensible to people asking how you decide what gets built when you have a designer, a head of sales, a head of marketing, the CEO, all asking for stuff to get built. "Aren't you just managing those guys' priorities?"

You're asked to be a visionary but also business savvy. To think long term, but be sensitive to the growth hack that would produce an effect just now. To stay the course, but also pivot whenever the evide

Open An instinctive understanding of the mechanics

In a Q&A after a surf competition, a surfer was asked how she would pick a new surfboard. She said, for her, it was all about how it feels under your arm. Have one look at videos of surfers picking out new boards - they all do this. They place the board directly under their arm, walk with it a bit, get a feel for the weight, wrap their fingers around the rail (the edge) of the board. Only after that do they start examining it up close and get a visual read on how they curve and angle. When they find one they feel will be good for them, they get their size made and take it out for a surf.

This feeling is key to a yearly staple internet series in surfing called Stab In The Dark. In SITD, pro surfers are given a batch of unidentified surfboards and they need to pick the best out of the bunch.

It’s pretty impressive, even if you are a surfer yourself, to watch pros be given a batch of seemingly identical surfboards and, through simple heuristics, immediately get a pretty good idea for who the shaper (the

Open How we do what we do

Every day I try to make sense of the dark art of being at the intersection of many different disciplines to create world-class experiences for Internet Economy products.

2 out of 4 isn’t too bad.

I’ve battled with explaining what I do every day for a while.

The Mini-CEO of the Product, the Good PM/Bad PM and so many other great examples have framed my thinking, and helped me come up with my own definition. This helps me understand the type of problems I solve with my teams every day and, as such, our lacks and faults, and how fundamental they are to what we’re creating.

I’ve divided the practice of Product Management into 4 operational planes.

From the ground up: a. Context > b. Hypotheses > c. Outcomes > d. Process

I then categorise each of those planes with 4 fundamental attri

Open Good managers, Great managers

One of the most important aspects of building great product organisations is to design a system where builders thrive. A small group of well-organized, ambitious yet humble, smart and driven folks can be an unstoppable force.

For managers, that means hiring and empowering direct reports so that they fulfil their aspirations and channel their strengths in the direction of a better product, but also of building teams that are able to discover that product that changes the course of the company, which they probably don’t know yet needs to exist.

So what is it that sets great managers (those that shape a person’s career and elevate them neck and shoulders above the rest) apart from the — hard to find in and of themselves — good ones?

Photo by James Coleman on Unsplash

Empowerment vs Inspiration

Good managers empower their teams to achieve their goals. Great managers inspire their teams to

Open Making decisions with skin in the game

Originally published Sep 30, 2018

It’s not uncommon to hear that most problems are people problems. I recently heard someone in product management say that 90% of her time was spent solving the people issues that got in the way of shipping.

How do great organizations solve this?

How do you minimize friction, streamline decision-making, and develop a culture of strong, yet weakly held, opinions, which need to carry the burden of proof?

The more the merrier

When starting, you find yourself in a one or two people show, running the business, calling all the shots and figuring out what comes next. You talk to prospective customers, you test stuff out with your friends, family, and acquaintances, you find creative ways to build out the next thing you think is going to make a difference and pay the bills.

You and your business partner have taken time off the safety of your previous jobs,

Open The Great Outsourcing of the Mind

Published on Feb 9, 2025.

You're trying to get some work done, as usual. Maybe you're putting a document together for your investors, maybe you're defining the requirements document for a feature, you're shaping up the technical architecture for a new component, you're doing financial analysis for a stock, writing a bit of marketing copy for your new ad, writing a legal document, planning a therapy session for one of your patients....

Chances are, you're using an LLM (a Large Language Model). You might still be starting a new conversation with it every time or, if you're an advanced user (you're ahead of the times), you have some custom workflows that make it feel more like a personal assistant that knows you and your past work.

To be honest, as of today, so should you. Some work is just boring, overrun, run-of-the-mill, time-consuming-task-BS.

You're just optimizing your workflow using a new tool. We all do it, all the time. It's a good thing.

Yet, this tool feels different. First, it's getti

Open The leftovers

Originally published August 18, 2022.

The other day a good friend was pushing me to give The Leftovers a chance, a 2014 TV show where 2% of the population suddenly vanishes. The series is about the impact an event like that has on social conventions, human relationships and the individual psyche. In a world where people believe others may simply vanish inexplicably the next day, there may be little shadow of the future to be concerned with - you simply can’t trust there will be a future for you, your loved ones, or others that cross your paths. Of course some will still persevere and keep their humanity, with themselves and others, but no ones keeps going unscathed.

A thought experiment my mind jumped to, was to think of a world where suddenly all our musicians disappeared, all our writers, or all our physicists. What would it mean for all of us, if any of the pivotal foundations of our culture or of our knowledge, simply collapsed overnight.

Sure, we could relearn things, we’ve built semi-robust sys

Open Building for fun

Originally published Mar 1, 2026

A familiar question

What should you build when everything is possible?

How do you build when everything is possible?

In another moment down went Alice after it, never once considering how in the world she was to get out again.

People today are throwing vibe coding around still like it's a dirty word. It was actually not meant as such by Karpathy when he coined it - he, himself, one of the great minds behind the current technological revolution. It was meant to be described as fun, light, somewhat careless coding. A return to having fun with code rather than spending weeks planning something that most times would turn out inconsequential. Either because it didn't work, or because nobody wanted it.

LLMs brought vibing back, and it horseshoed in two groups of very different people who were aching for a simpler time. On one end of the spectrum, those for whom coding was like dark magic. Impossible to approach, yet mysteriously powerful. All of a sudde

Open Stop Estimating, Start Budgeting

Originally published Nov 4, 2019

Forecast like you mean it — https://xkcd.com/1606/

Why do we so often ask teams to estimate in detail how much effort is required to build a product, and to that upfront? There’s evidence that this lead us to output-oriented thinking, premature optimization, bloat and generally a commitment to suboptimal solutions that are designed with too many assumptions and a lack of clarity on the problem space.

Yet the main reason, I’d argue, is that estimation is an entirely rational risk mitigation strategy. Some of the reasons might be that:1) we’re promising to build a product for price X, when it’s going to cost us more than X-M, where M is our minimum acceptable profit margin. Maybe we don’t want to build this thing.

2) there are explicit and irreversible costs to not meeting a deadline and we want to minimize the risk of not doing so, so that we can organize and

Open DevOps is dead — Let’s be DevProds

DevOps is dead — Let’s be DevProds

Originally published Apr 19, 2015

We’ve seen the move from a programmer plus operations culture to the emergence of the DevOps culture. The start-up movement, where small teams rule, the emergence of tools that allow developers to set-up complex infrastructures easily, others that allow developers to create powerful automation and configuration scripts and the recognition that small, empowered teams can accomplish great things, were all factors that brought together the IDE (or Vim ☺) and the shell, and let developers expand their reach. The DevOps culture had risen, creating a lot of opportunities for these newly created unicorns.

This small step was great and brought a lot of flexibility and power to teams. Combined with cheap and easy to set up cloud services, actual miracles happened.

DevOps is Dead. Long live DevOps.

So now it’s 2015. We’re happy, we’ve settled, we’ve accomplished a lot and we should congratulate ourselves.

DevOps worked.

So

Open You're always either late or wrong

Originally published Mar 31, 2018

Humans want to put things into categories. Life is easier that way. At work, particularly for software organisations, planning often means putting your work in a box: Is it a Project work stream or an Experimentation one? Is it Engineering or Product? Is it Date-driven or Result-driven?

Having categories is great because they allow everyone to quickly grasp the fundamental characteristics of a given piece of work, without having to look too hard at the specifics. System 1 thinking will do the trick. We know that for something to be a features, for example, it needs a set of requirements. A date-driven initiative, requirements plus a deadline. Outcome-driven streams are often date-flexible, but assume a static goal.

Regardless of how you categorize, then, you’re reducing the dimensionality of the problem to make it seem understandable, achievable, ambitious yet realistic. Let’s look at some examples.

You have to choose!

The project management trifecta / trip

Open The product team and the elephant

The ancient Indian fable goes that once, an elephant was brought to a village of blind men. They had never been in the presence of one, so as the extraordinary animal stood in front of the men, they would touch it and feel it to learn the details and intricacies of its shape.

Each of the men would touch a different part of the elephant, and would go on to describe the elephant as their experience allowed.

Those who touched its tusks, would say the animal felt hard and pointy and made of marble. Those who touched its side, and feeling a tall, rugged surface, said the elephant felt as if it were a wall. Then those who touched its ear came and said the elephant was nothing of the sort. They thought it was thin, flappy and was more like a fan.

The men argued for a while but couldn’t reach consensus. They refused to understand how others could so stubbornly stand by their (undoubtedly flawed) perspectives. They argued and some even came to blows, until one of the elders demanded they stopped and listened

Open You'll never believe what actually works

I have an interview question guide. Anyone who's run more than a dozen interviews for any particular role will have some version of this.

There are skills you want to assess, ways of asking questions that drive better, more informative answers, and you want to have a large enough menu that'll fit the level of the candidate you're faced with, which more often than not can't really be told by looking at their resume. Mine is pretty good, because it stands on the shoulders of giants. I've copied, tweaked and polished questions from colleagues, other PMs and Product Leaders in the industry, added my own, and now I have one I'm happy with.

Here's the thing though. These help me separate a good candidate from a bad candidate. But a great candidate? One who will hit the ground running by grabbing the org by its horns, grappling with it and harnessing its energy towards a much better product. Much much harder. More of an art than a science.

There are general things that a Product person has to demonstrably

Open Keeping score on delight

How much can you spend on shipping, neglecting the unnecessary, quote nice-to-have, moments of delight, before the scale tips over?

When we’re creating something new, we’re unleashing our model of reality. We do that in an attempt to solve a problem our models have detected and in our belief that perception is shared by others. On top of it all, our solution will be able to extract value from addressing the problem.

These same models of reality of course apply to software products. Our creations are cheap, tremendously easy to modify, and arguably a lot harder to destroy than any of the human constructions that came before us due to their decentralised and intangible nature. For us, technologists, there is a model of what software is, what it should look like, and what can be done with it. We work hard to bridge the margins between what we think it is we’re solving and how others will interpret its benefits.

The industry quorum dictates that the way to bridge this perception gap is to fail fast. To i

Open How To Start an IoT Product

How to start an IoT product

Originally published: Apr 1, 2015

So you have a company, a start-up, or just an idea that will change the world of material things. The Internet of Things presented the opportunity and you’re ready to take it!

Yet, like with any product, you need more than an idea. You need to make it happen. Here, I talk about how we design and build IoT products at Citibrain. We are focused on Smart Cities, but the possibilities are endless. I suggest you start with Postscapes’ IoT resources to get your blood pumping.

This post focuses on IoT, but we propose an approach based on lean and agile methodologies. We’re looking at creating an MVP for IoT, so this is about maximising the product’s value for your potential customers using the least amount of effort possible. So let’s start from the top.

https://www.youtube.com/watch?v=Yd6SJxan0jo

The problem

So you had this brilliant idea. The first thing you need to do is create an hypothesis. This means stating the probl

Open “The Design of Everyday Things”

I take it this is pretty common. Someone reads “The Design of Everyday Things”, has an epiphany, and then goes off to become a better designer, developer, product manager or overall person.

Why is it such a good book?

First of all, Don Norman knows his stuff. This does not read like one of those books written by people that know everything about everything. This reads like Norman’s life’s work. He has spent a lot of time thinking about good design, what great usability looks and feels like. Most importantly, he has spent a lot of time thinking about how to explain it to others so they could understand it too.

He lays it out in simple, understandable terms. He defines reference models to explain interactions between people and objects or digital products and gives practical examples of their usage. He shares his experiments, real world use cases and how he reached his conclusions. You go

Open Design Sprints in the Real World

Design Sprints in the Real World

Originally published Jul 27, 2016

When faced with a complex problem, whether in terms of the idea itself (what), its execution (how) or the organizational or personal challenges you’ll face to make it happen (who), the processes of design thinking and lean help you remove some of those barriers through cycles of validated learning. From clearly understanding the problem to finding cheap ways of testing and validating your assumptions, you can magnify your chances of success before writing a single line of code.This is a powerful value proposition and, thankfully, many in the software industry are taking it in and applying it to their projects. It is incredibly important to iterate on your assumptions and increase their exposure to potential customers. This time around, faced with a complex problem with great potential, my team and I turned to one of the most widely known validation methodologies out there — the Design Sprint — to put our assumptions to the test.

Open Fearless Products

Originally published Feb 28, 2017

That some things are more important than others seems obvious. However, product creators often forget that any solution will invariably expose their points of view.

Being afraid to see your opinions and insights voiced will invariably result in bland, grey, soulless experiences.

“Here’s everything everyone has ever cared about because we couldn’t decide what we were about”.

Not only will the result be boring, it’ll be unnecessarily confusing.

*“The Authentic Italian” — The imaginary story of a failed pasta place * You look around your neighborhood. There are 10 different hamburger restaurants, 7 of them call themselves “gourmet”. There are also 2 pizza places. They serve pasta too, but they’re franchises… Nothing wrong with that, but they’re really not the kind you’ve tasted on your Summer trip to Italy.

![1_uLi0mjqA8-ljfu7agUA0rA.webp](https://w

Open Working Backwards - what is your product all about?

A guide to building better products by visualizing the end game, lessons learned from using Amazon’s Working Backwards approach.Visualizing the end game

There are many blog posts out there outlining Amazon’s approach to Product Development. It focuses on visualizing the end state before you introduce any other (often more complex) validation techniques to your ideas.

These are lessons learned from testing these ideas with cross-functional product teams.

What’s your ideal end state? — The Press Release

Let me start by saying I believe in product vision. Not crystal-ball-type vision. But in a belief that you are the sum of your knowledge and insights — which can lead you to visualize an end state for your product or company that’s unique to yourself and can thus go against the status quo and that of incumbents.

We used the Lean Startup terminology and called that a Leap Of Faith Assumption (LOFA, read loafer in a British accent, for bonus points). When you use Working backwards you start by e

Open Building your Startup's Culture with Pirate Metrics

Building your Startup's Culture with Pirate Metrics

Originally published Apr 2, 2016

One of the hardest parts about scaling a company is keeping its culture alive as it grows. You don’t want it to stay the same — it should evolve. Yet you also don’t want it to change too much — the core values should stay the same.

A lot of startups build their culture on perks and benefits. Brand new Macbooks, standing desks, free soda and donuts, beer in the office, Nerf wars… While these are all pretty cool, they are a gimmick. They can’t be the foundation of your company’s culture, not unless you want your culture to be as plastic as it gets. Don’t get me wrong, I love a good Nerf headshot as much as the next guy, but I wouldn’t work for you because of them.

I propose we treat our culture like we want our people to treat our product.

So let’s work with Dave McClure’s Startup Metrics for Pirates framework and scale our culture into a freakin’ Unicorn. Quantifying the 5 dimensions of the Pirate Metrics to

Open OKRs, are they good for you?

Originally published Jan 22, 2018

When we talk about organisational models and systems of incentives as applied to companies, the conversation often (as with other topics) falls into dualism - implementation are wrongly pictured as just black or just white, nuance is removed from the conversation and the pitfalls of applying an incentive structure and goal-setting framework to an organisation are a second class citizen.

By system of incentive, I generally mean an organisational framework that allows departments and teams to define and pursue a given strategy, set goals, monitor their progress and celebrate their achievements. These frameworks end up defining which behaviours get rewarded, who progresses in their careers, which teams and individuals are considered high-performers, what metrics are in the company’s dashboards and what colours they’re displayed in.Geckoboard’s Mixpanel example integration with key web metricsIt is clear that these shouldn’t be taken lightly. Every rational individual withi

Open Conversion Rate

Let's look at one of the primary indicators companies use to increase their Average Revenue Per User, build audiences, increase orders and which has a whole field of optimization dedicated to it: Conversion Rate (CR).

Talking about Conversion Rate

The basic formula is dead simple:

Conversion Rate = Completions / Users

So if you run a commerce operation and your ultimate completion is an order, say you had 1000 users and those users made 10 orders, your conversion rate is 1%. Easy, right?

I agree. It’s easy to monitor, easy to compare, but over time, and as you grow, looking at all your users and comparing them to all your orders, becomes unhelpful when it comes to making product decisions.

Breaking it down

The most common and useful way to break Conversion Rate down is to use time. Say you’re looking at users who convert within the first day we’ve seen. them on the website. We’re now analyzing something like:

Conversion Rate (1d) = Completions (1d) / Users (1d)

But… sess

Open LTV

How to move the LTV needle

In general, any loyalty scheme is built around two key factors that brands use to incentivize customers in order to drive their Lifetime Value (LTV): one that’s financial, another that’s emotional.

On both accounts, what we’re doing is creating an incentive for our user that generates a net positive effect on Average Revenue Per User (ARPU), within a reasonable payback period given the SAC/CAC we incurred in (Subscriber Acquisition Cost/Customer Acquisition Cost), our Running Costs (and runway) and our Cost of Capital (WACC).

Usually, that is done by offering the customer a discounted offer on their current or proximal purchase / spend (with said discount in the form of price, promotion, convenience — such as shipping costs or upgrade options), which actually negatively impacts someone’s ARPU within a short time frame, while lowering the cost of their preference o

Open Product Strategy: Visualized

There is a recurrent thread going on in tech circles that contrasts 1) the philosophical approach of companies that have adopted the lean startup practice of rapid customer development cycles and pivoting with your learnings vs 2) companies that are thesis-driven, have a big mission and are relentless in pursuing it, bending reality to their will — using examples of product visionaries like Jobs, Gates and Musk.

One very recent example (at the time of writing):

The conversation has degraded into a love/hate discussion around companies doing experimentation, as if being rigorous about your hypotheses and attempting to invalidate your riskiest assumptions somehow precludes you from having a vision of the future and how you’ll change it. I’ll try to address some of the confusion around that in another post.

This one, I’ll use to structure how a Product Manager should think about t

Open Job Canvas

A tool to maximise learning when going from customer motivations to execution. A simple canvas to visualize your team’s work to discover, execute and integrate around the job to be done.

The call of progress

The Job Canvas starts from the Job To Be Done. It assumes you have talked to customers, collected insights from the data at hand and explored the dimensions of the problem you’re trying to solve — and then summarized it in the Job To Be Done format. I’ve typically gone for Alan Klement’s proposal and chosen as the cornerstones of my Job Story. This short format can encompass known trajectory (with situation), pain points (with motivation) and rightly focuses on outcomes (vs outputs).

*So what does the Job Canvas do? * You would hire the Job Canvas to help your team outline the key steps and measures you’re using create a solution that can itself be used for the job you’ve identified. These define the state of what you know in the context of what

Open The Toolkit

The Product Playbook

A Playbook of Product Management Techniques

Intro

A Product playbook is something I've wanted to do for a very long time. Product management is an art, insofar as everything that requires human intervention to create something is art. But there is causality in what product people do and their outcomes, how the interactions between product managers, designers, developers and other stakeholders turn vision into usable objects or interfaces. This playbook aims to become a cooperative effort to describe the multiple ways one can turn insights and ideas into products that solve problems.

The concept of the playbook is inspired by sports. The best explanation I've seen is the one by Jon Lax in "Great Products Don't Happen By Accident"

The product playbook gives people plays they can apply to specific moments in the product development workflow. Each play should follo

Open Recommended reading

I recently put together a list of articles, videos and books I think people moving into a product role should read to get a good grasp of the fundamentals.

These are just a starting point to help new Product Managers / Owners / Humans think about problem-solving in the internet age and give them mental models. If that’s you, you’ll need to know that they’re not recipes but, in time, they can help you create your own. In the end, building things people care about is hard work, and it’s all on you. Good luck!Articles / Essays

*We don’t Sell Saddles Here * Stewart Butterfield, Slack’s CEO, wrote this brilliant memo 2 weeks before Slack launched. It’s about the meaning of what you’re building. That matters a whole lot more than what the product says on the tin: https://medium.com/@stewart/we-dont-sell-saddles-here-4c59524d650d#.ldajcg1ds

*Thinking Exponentially — 10x not 10% * Ken Norton, now a partner at Google Ventures, explains why Product Managers should always be the strongest advocates for

Open There's an AI There

AI In the Middle Observability, Evals, Memory, RAG - The best PM in the world has severe memory loss Human in the loop Processes, their language, shared history, culture and org memory The way things improve What's been hard will stay hard