Discover more from Product State
Austin Yang on quantifying feature value, balancing truth-seeking with POV, and getting started with no-code PM tools
Product State Q&A
EC: How may PMs quantify the value of a product feature?
AY: I’ll try to answer this in two parts — the ‘why’ and the ‘how.’
Starting with the ‘why:’ To me, the goal of quantifying feature value is to simplify the complex nature of how individual features create value together. It is all about providing a frame of reference that is easy to digest, helping you and your team to make better decisions.
What it shouldn’t be used as is a performance review metric. When people need to ‘prove’ the value of their work, it creates all sorts of problems.
Moving on to the ‘how:’ The common method of quantifying feature value is to assign a dollar value to each feature using some sort of formula. But I find that both too simplistic and too convoluted at the same time.
It is too simplistic in the sense that it disregards the relationship between features by comparing them on a single scale. It is too convoluted in the sense that product teams often try to apply some overly complex model to generate an estimate. At best, it gives you a guesstimate that you could’ve gotten in a much shorter time. At worst, it gives teams a false sense of certainty.
What I find more useful is to map each of your features onto a 2x2 matrix based on:
The % of users who find the feature valuable (breadth)
Its value relative to other features (depth)
This framework is commonly used in pricing research to determine feature packing, but I think it is also useful in the broader product management context. You will end up with four buckets of features:
Differentiators — Most users want them and will pay extra for them.
Table stakes — Most users want them but won’t pay extra for them.
Hidden gems — Only some users want them but will pay extra for them.
No one cares
I don't believe there is a single method to capture the demand or relative value of each feature. It has to come from your overall user understanding.
Some might argue this is too subjective. But trust me, if your team spends enough time talking to users, analyzing data, and discussing insights, you'll end up with very similar conclusions.
EC: How should PMs balance objective truth-seeking and intuitive, opinionated POV?
AY: I actually don’t see them as two opposite ends of a spectrum, but rather as two interconnected parts of a loop.
Your intuition and opinions should be informed by facts, but fragmented facts alone won’t help you build a product — you have to piece them together with your own thoughts and logic.
Because there is no trade-off to be made here, you should always try to do more of both.
EC: How can ‘No Code’ tools help PMs, and what should a PM do to get started?
AY: The concept of no-code is nothing new. Most PMs have used no-code tools without realizing it. But recent advancements in the no-code space have drastically pushed the boundaries of what's possible.
We often hear engineers and designers complain that PMs don’t know enough about development or design, therefore can’t make good day-to-day decisions.
Learning no-code is a great way to fix that.
It is a lot cheaper than going through a boot camp or getting a degree. It is also a lot more effective as you have the freedom to build whatever you want, instead of merely following instructions to build a basic, cookie-cutter project.
The fact that you don’t have to memorize syntax also gives you more time to focus on the core concepts. For example, using Airtable helps you understand relational databases. Using Webflow helps you understand HTML/CSS. Using Zapier helps you understand API and automation.
If you’re part of an early/mid-stage startup, having the ability to ship something on your own also makes you immensely more valuable. While other teams spend weeks scoping out a feature, you could whip up a working version to gather feedback within days.
In my view, no-code is just a natural progression of the digital world. For example, most users of Softr (the no-code platform I'm building) work in non-tech SMBs. If they can build functional software, there is no reason why PMs—who get paid to build commercial-grade digital products—can’t do the same.
If you’re just starting out, here are some tools that I recommend exploring:
Web app: Softr
Mobile app: Adalo
Automation: Zapier, Make
Chatbot: Landbot, ManyChat
I’d also recommend that you join a few communities, such as Makerpad, 100 Days of No Code, or simply searching #nocode on Twitter / X.
Have fun building!
“The goal of quantifying feature value is to simplify the complex nature of how individual features create value together. It is all about providing a frame of reference that is easy to digest, helping you and your team to make better decisions.”
- Austin Yang
Thanks for reading Product State! Subscribe for free to receive new posts and support my work.