Everyone talks about "product thinking." Few people describe what it looks like on a Tuesday afternoon, in front of a blank screen, with a messy user problem and a team waiting for a decision.
Theory says "focus on the user." Practice hands you three users asking for three different things, a sales lead promising a feature to a client, and an engineering lead warning that the payments module can't take another patch.
Product thinking is not a framework you recite. It is a set of habits for making good decisions when the information is incomplete. Here is what those habits look like in the real world.
Picture a small logistics startup in Lagos. Riders deliver parcels for online sellers. In one week, the team receives:
All three are reasonable. You can build one this sprint. What do you do?
The first instinct is to wait for better data. It rarely arrives. Support tickets are half-written, analytics events were never set up for the screen you care about, and the loudest seller is not the typical seller.
Product thinking starts by naming what you know, what you are assuming, and what you can find out cheaply this week. In the logistics example, you might know that rider logouts appear in 40 support messages, assume sellers want the map to reduce "where is my parcel?" calls, and be able to check that assumption with five phone calls.
Writing those three lists down takes twenty minutes and removes most of the panic.
Every product has one job it must do well. For the logistics app, it is getting a parcel from seller to buyer and proving it arrived.
Ask of each request: does this stop the core job from happening, or does it make a working job nicer?
Once you frame it that way, the rider logout is the clear priority, even though it was the quietest request.
A decision nobody can find is a decision that gets re-argued every week. Write a short note: what you chose, what you are not doing yet, and why.
We are fixing offline session handling for riders this sprint. The live map and referral programme are paused until delivery completion rates recover. We'll revisit on the 15th with the new completion data.
That paragraph does more for the team than any framework diagram. Engineers know what to build, the founder knows the referral idea is parked rather than rejected, and sellers get a reason when they ask about the map.
It is not having an answer for everything. It is not choosing the most impressive feature. And it is not consensus. Good product people disagree openly, decide anyway, and change course when the evidence changes.
In our cohorts, participants work on product problems that come with incomplete information on purpose. They make the trade-off, write the decision note, and defend it to mentors who push back. The goal is not a perfect answer. It is building the habit of deciding well under pressure.
Want to build this habit with real product problems? See when the next cohort opens
