Product strategy

The problem this solves

Most software projects are not killed by bad engineering. They are killed by a scope nobody agreed on, discovered in week six, when changing it costs four times what it would have cost in week one.

The usual response is a discovery phase that produces a deck. A deck is a description of a plan, not a plan. It cannot be estimated, cannot be sequenced, and quietly leaves every hard decision to whoever builds it — which means the decisions get made under deadline pressure by someone who was not in the room when the budget was set.

This is a week of work that ends in something buildable instead. The test we hold it to: could a senior engineer who has never met you pick this up and start, without a follow-up call to find out what you actually meant?

What the week looks like

It starts with one structured call. Not a chemistry meeting — a working session where we pin down what the product has to do, who it has to do it for, and what the constraints really are. Budget and deadline are part of the brief, not something revealed later.

From there we work the scope down. Most ideas arrive as a list of everything the product might eventually be. The useful output is the smaller thing that is worth shipping first, plus an honest account of what we are deliberately not building yet and why. Sequencing is the whole job: what has to exist before anything else can be tested, and what can wait without costing you a rebuild.

By the end of the week the scope is priced. Not a range wide enough to be meaningless — a number tied to a specific set of deliverables, with the assumptions written down so you can see which of them, if wrong, would move it.

Bilingual is a scoping decision, not a feature

If the product will serve Arabic and English users, that belongs in the plan from day one. Retrofitting right-to-left support into a product designed left-to-right is not a translation task — it touches layout, iconography, input handling, date and number formatting, and every assumption about which edge a thing is anchored to.

We scope it up front because we have done it the other way and watched what it costs. Techiato products ship bilingual by default; the strategy week is where that gets priced honestly instead of discovered late.

What you walk away with

• A written brief: what the product does, for whom, and what success looks like — specific enough to estimate against.
• A scoped roadmap with an explicit first release, and the deliberately-deferred list that goes with it.
• A timeline tied to that scope, with the dependencies that drive it named.
• A price for the build, with the assumptions behind it written down.
• An honest answer on the parts we think are risky, including the ones that argue against building at all.

Where this has gone

Manadeeb is the clearest example of scoping doing its job. It is a delivery-rider ERP for operations running hundreds of riders, and the full version is a finance, inventory and HR system as well. Rider management ships first — registry, shift attendance, per-rider scorecards and an audited approval trail — because that is the part that replaces the spreadsheet everyone is actually fighting with. The rest is sequenced behind it rather than built in parallel and launched late.

Manadeeb case study

Common questions