How I Make Product Decisions Under Technical Constraints

Start with the pain, not the architecture

Technical product decisions often look binary from the outside: ship the fast solution or build the technically stronger one, optimize what exists or invest in a larger change, accept a customer request or protect the roadmap.

My first question is simpler: can the faster option solve the customer problem well enough to put something real in front of users and learn?

If it can, I prefer to get to that evidence first. If the need is real and the solution is useful, deeper optimization becomes easier to justify. Technical quality still matters, but I sequence the investment according to what we have actually learned.

Ship enough to replace assumptions with evidence

This was important in Sepas. The product had already spent a long period in development before public release. I did not want the next decision to be another large pre-launch investment based mainly on internal assumptions.

The priority was to reach a usable market-facing release, instrument the experience, and observe real behavior across onboarding, assessments, engagement, partner invitation, and subscription activity.

Subscription purchasing was one of the behaviors that mattered precisely because it could not be validated by internal discussion. The product needed to be in the market before we could learn from that signal.

The principle I took from that work is: do not spend heavily proving how complete a product can become before you have evidence that the underlying need is worth the investment.

A technical bottleneck becomes a Product problem when the customer feels it

At WiseTrack, the platform was receiving a high volume of event data while customers were querying that data through dashboards. As the analytical workload grew, heavier queries became visibly slow in the customer experience.

At that point, the database issue was no longer only an Engineering concern. From the customer's perspective, the product was taking too long to answer a question.

Keeping the existing MySQL path was the lower-cost option, and we had already tried improving it multiple times — roughly three optimization rounds — without reaching the outcome we needed. Repeating the same approach would have consumed more engineering time without changing the underlying constraint.

That evidence changed the decision. We moved the relevant analytical workload toward ClickHouse. In one recorded session-overview API example, response time improved from approximately 1.2 seconds to 0.25 seconds.

The lesson was not that one database is universally better than another. It was that previous attempts are evidence too. When a lower-cost path repeatedly fails to solve a customer-visible problem, trying it again may actually be the more expensive choice.

Customer requests are evidence, not automatic roadmap items

I have also had to say “not yet” to customer requests. A request matters, but it still has to compete with capabilities that are more important to the product direction.

At WiseTrack, competitive research across products such as Adjust, AppsFlyer, Adtrace, Metrix, AppMetrica, Amplitude, and related measurement patterns helped show which capabilities were becoming baseline expectations in the category.

When requests compete, two factors weigh heavily in my judgment: the business value of the request and the strategic value of the customer making it. Request count alone is not enough. The job is to understand what the request means for the customer and for the product.

Prioritization is not enough if you do not understand the pain

Product management is often reduced to prioritization frameworks. Those tools can help, but they are not the starting point for me.

A good Product Manager is not simply someone who prioritizes correctly. A good Product Manager understands the pain behind the request.

Without that understanding, prioritization becomes spreadsheet management. You can rank Feature A above Feature B while still missing what the customer is actually unable to do.

Understanding the pain creates better questions: what is the customer trying to achieve, how expensive or frequent is the problem, can we solve it with a smaller change, and what evidence would justify a larger investment?

External interruption is not the same as product failure

Houbad reinforced another part of this framework: be precise about why validation stops.

The smart-ambulance work reached an initial MVP in approximately seven months and was tested with EMS on two real ambulances. My preferred next step was to continue toward a stronger real-world MVP and broader validation.

That path was interrupted by an external conflict-related disruption: required hardware was lost, and continuing would have required rebuilding and developing parts of the hardware setup again.

The project did not stop because we had concluded that the product had failed validation or that the need did not exist. The interruption changed what could be tested next.

I still separate the intended next step from what had actually been proven. What we had validated was a controlled EMS field test on two real ambulances. Broader real-world deployment remained unvalidated.

A Product Manager should be ambitious about what comes next while being precise about what has already been proven.

Pain · Proof · Investment

I think of the six steps below as one loop: understand the pain, create trustworthy proof with the smallest credible solution, then invest according to what the evidence justifies.

Proof does not mean certainty. It means evidence sufficient to support the next decision while keeping the remaining uncertainty visible.

1. Understand the pain. Do not begin with the requested feature or preferred technology.
2. Find the smallest credible solution. If a simpler option can solve the problem and generate useful evidence, test it first.
3. Observe real behavior. Shipping matters because it turns assumptions into evidence.
4. Treat failed attempts as evidence. Repeating the same lower-cost approach has a cost too.
5. Invest after validation. Deeper technical investment is easier to justify when the need is demonstrated.
6. Protect the evidence boundary. Be clear about what was shipped, what was tested, what worked, and what remains a hypothesis.

The principle I keep returning to

Understand the pain first. Ship the smallest credible solution that can produce trustworthy evidence. Then invest according to what you learn.

Technical Product Management is not about choosing between product thinking and engineering thinking. The interesting decisions happen when you understand enough of both to know when a technical constraint has become a customer problem, when a quick solution is sufficient, and when the evidence finally justifies something bigger.