Good product prioritization is mostly the discipline of deciding what not to build. We are a small team with a longer list of promising ideas than we have capacity to deliver.
Our product prioritization filter
Every candidate goes through the same three questions. Is there a real, repeated operational problem behind it, not a preference but something costing people time every week? Do we have genuine insight into the industry, or would we be guessing? And can we ship something narrow but complete within a horizon we can actually sustain?
An idea has to clear all three. Plenty of attractive ideas fail the second question, and that is usually the one worth respecting. Building for a market you only understand through research is how teams produce software that demos well and gets abandoned in month three.
Narrow and finished beats broad and partial
A platform that does one part of the job completely will be adopted. One that does six parts approximately will be evaluated and declined. When we scope a release we look for the smallest slice that someone could rely on without a workaround.
This is easier to say than to hold to, because a broader scope is usually easier to sell internally. The corrective is to define, in advance, what “finished” means for the slice, and to refuse to widen it until that definition is met.
What we deliberately avoid
- Building for a market we only understand through research
- Features that exist to match a competitor rather than to serve a user
- Anything that increases the amount of data entry required to get value out
- Commitments to availability dates we are not confident we can meet
- Work that only makes sense if several uncertain things all go right
Sequencing matters as much as selection
Two features can both be worth building and still be worth building in a specific order. We prefer work that reduces uncertainty early, because a cheap answer to an open question is often worth more than an expensive increment of something already understood.
Marty Cagan’s writing on product discovery covers this ground well: the point of early work is to learn, not to produce.
Saying so honestly
This is why our platforms carry status labels rather than launch announcements. “In Development” means what it says. We would rather be accurate about where something stands than borrow credibility we have not earned yet, and customers tend to remember which companies did which.
Read next: What an on-demand logistics platform has to get right. Or see partner with us.