How I decide what to build
First decide a goal, then build towards it.
This approach comes mostly from my freelance experience. When working in teams, I didn’t have full ownership of what to build. Instead, the teams I’ve worked with often followed what I call a “pipeline mode”, which looks like this:
Somebody decides what to build → Somebody crafts a design from it → dev team builds it → Repeat
Now this “waterfally” model creates some problems:
- It hides the “why” for the builders.
- It doesn’t guarantee alignment between product, design, and tech. This often leads to what I call the class project paradox: everyone works on their part in isolation, and only later do we try to mix everything together.
- It hides the impact of the work to each team member, and this can demotivate people.
To me, the missing piece in this model is an agreed goal and clear ownership.
My way to build things
When I went full time into freelance, I knew I needed a new method to build products. A method aligned with my clients needs, but aiming for impact on relevant metrics, not on vanity ones. So I came with this method.
First, I define 2–3 goals per quarter for each client. Each goal is backed by data that tells me “this needs to improve” and is paired with a global hypothesis.
I focus on this areas:
- Activation. Taking users to perform the action we want so they can discover product value.
- Retention. Is easier to keep a user than to get a new one.
- Acquisition. This is usually a shared effort with marketing people, but I do my best to support them here.
In my experience, improving this areas has the sideeffect of improving MRR and churn rate. I don’t set goals like “Increase MRR”.
A real example, Fútbol Sesión
Goal: Simplify exercises creation process
Area: Retention. If it takes less time to create an exercise they will come to create more, the effort to use the product is perceived as less, and users are happy because they have tools to be more productive.
Evidence from data: Creating an exercise from scratch takes 12 mins on average, users are happy with the feature (feedback from user interviews + surveys) but would like a faster process.
Hypothesis: If we reduce the time needed to create an exercise, users will engage with the feature sooner and experience its value earlier. This should lead to more exercises being created and higher retention in the product.
Once a goal is defined, I propose new features or improvements for the product. Each one needs a clear way to measure its impact. From the example above, I proposed these:
- Allow users to duplicate exercises [low complexity, high confidence, high impact] → Measure feature usage
- Allow users to create template exercises [mid complexity, mid confidence, mid impact] → Measure the number of templates created and used
I aim to work first on the ones with low complexity and high impact. When I have low confidence on a solution, I default to talking to 5-10 users, running a survey targetting an specific segment, running an A/B test or gathering additional product metrics.
So now, my method is something like this:
Set quarterly goals from data → Propose metric-boosting features → Build lowest-risk ones first → Measure → Grow
Why goals and not OKRs
An OKR is something like this: “Increase the percentage of users who complete onboarding from 45% to 65%.”
The problem that I see with OKRs is that for clients it sounds like a promise, and they usually take it like that. While I’m committed to helping them grow their products, I cannot guarantee those and it puts a huge amount of pressure on me because I need to reach that result.
What I can guarantee is that everything I build contributes towards a goal, like “improving user onboarding activation”. At the end of the quarter, I can show the client progress toward that goal, but I don’t want it to become a performance evaluation. That’s why I avoid OKRs.
I discovered this tip in the PostHog handbook, and it has been incredibly valuable to me. See Goal Setting