How long should discovery take?

Weeks, not quarters. A few focused weeks of workflow observation, interviews, and data audits will surface the structural findings that matter. What remains uncertain after that is usually better answered by building an instrumented first version than by more research.

What belongs in a product design strategy document?

The pillars and the tradeoffs behind them, the explicit non-goals, the tensions the product must hold rather than resolve, and what the data model must support. Short enough to be read, specific enough to be argued with, stable enough to outlive its first quarter.

How do you keep an MVP from becoming the permanent version?

Scope it as a question with kill criteria, design the data model for the roadmap rather than the demo, and plan the instrumentation before launch. A first version earns its second with evidence; without that framing, whatever ships first calcifies.

Product Strategy & Acceleration

The most expensive design decisions happen before anything is drawn. I take products from a blank page: discovery, the domain model, the strategy document, the first shippable version.

Discovery
Zero-to-One
MVP Design
Prioritization

How I work here

Discovery is structured and short. On the localization platform, a three-week sprint of workflow observation, cross-region interviews, and data audits surfaced 204 workflow variants and attributed the failure modes precisely enough to design against them.

Strategy gets written down. I authored the product design strategy that aligned product, engineering, and operations leadership around three pillars; a document that holds across teams beats a deck that survives one meeting. Prioritization under governance and compliance constraints is part of the same discipline.

First versions are scoped to earn their second. The commercial real estate platform shipped as an MVP whose architecture already carried the full leasing cycle; earlier, a private banking MVP combined portfolio management with a client-experience layer.

Discovery that ends in decisions

Discovery is time-boxed and instrumented, not an open-ended listening tour. The working set: observation of real workflows, interviews across the roles that disagree with each other, and audits of the data people actually keep, because the private spreadsheet is usually the honest requirements document. Synthesis attributes failure precisely: which errors trace to inconsistent fields, which delays to hand-offs, which workarounds to distrust of earlier automation.

The output is a set of decisions, not a report: what the product is, which tensions it must hold rather than resolve, what the data model has to support. If discovery does not change the plan, it was theater.

Strategy is a written instrument

Alignment survives in documents, not in meetings. A product design strategy worth the name states the pillars, the tradeoffs behind them, and the explicit non-goals; it is short enough for leadership to read and specific enough for engineering to argue with. Each pillar names the outcome it should move and the decisions it forecloses, so a dispute two quarters later gets settled by citation rather than by whoever remembers the meeting loudest.

Prioritization then happens against the document under real constraints: compliance calendars, platform dependencies, team shape. Presenting choices in operational terms (time-to-decision, data integrity, delivery risk) keeps the discussion about outcomes instead of aesthetics.

First versions built to earn a second

An MVP is a claim about what matters most, made with architecture that will not need to be disowned later. First versions get scoped around the workflow that proves the product's reason to exist; the data model is designed for the roadmap rather than the demo; kill criteria are stated up front (an adoption floor, an error ceiling, a date) so momentum cannot substitute for evidence.

Outcomes get framed honestly from day one: projections labeled as modeled, instrumented pilots planned before launch, and the discipline to treat a first version as a question rather than an answer.

What this covers

Time-boxed discovery sprints and synthesis
Product design strategy documents
Domain and data-model definition
MVP scoping with kill criteria
Prioritization under governance constraints
Roadmap shaping with engineering leads
Modeled versus measured outcome framing
Executive and stakeholder alignment

The work behind it

Content Localization Workflow Platform
Three-week discovery sprint; authored the strategy that aligned product, engineering, and operations leadership.Case study →
Enterprise Real Estate Management System
Zero-to-one MVP; 60–70% reduction in proposal preparation time (modeled, MVP stage).Case study →
Private Banking Platform
MVP design for a private banking fintech product (2019, archive).

Questions, briefly

How long should discovery take?: Weeks, not quarters. A few focused weeks of workflow observation, interviews, and data audits will surface the structural findings that matter. What remains uncertain after that is usually better answered by building an instrumented first version than by more research.
What belongs in a product design strategy document?: The pillars and the tradeoffs behind them, the explicit non-goals, the tensions the product must hold rather than resolve, and what the data model must support. Short enough to be read, specific enough to be argued with, stable enough to outlive its first quarter.
How do you keep an MVP from becoming the permanent version?: Scope it as a question with kill criteria, design the data model for the roadmap rather than the demo, and plan the instrumentation before launch. A first version earns its second with evidence; without that framing, whatever ships first calcifies.

Elsewhere on this site

If this is the territory your product lives in, the case studies carry the detail and the contact page carries the practical part: roles, embedded engagements, and where to start.

Contact

Access code