Define success without inventing outcome metrics
A credible success measure needs a definition and an evidence source before it needs an ambitious target. Distinguish baselines, hypotheses, and observed results so a product proposal does not manufacture its own business case.
Read MoreTest a prototype before committing to implementation
A prototype should answer a risky question, not just impress a stakeholder. Select realistic tasks, observe users without coaching, and distinguish interface evidence from the technical proof required before implementation.
Read MoreSeparate product assumptions from verified requirements
A requirement can look authoritative simply because it appears in a polished document. Separate evidence, inference, and policy decisions so teams know which assumptions need testing before they become expensive commitments.
Read MoreRun a discovery workshop with decisions to make
A discovery workshop earns its time when it resolves a specific decision or exposes why that decision is premature. Prepare evidence, decision rights, and alternatives instead of starting with an unrestricted feature brainstorm.
Read MoreWrite acceptance criteria with concrete examples
Acceptance criteria should let business and delivery teams recognize the same result. Use concrete starting conditions, actions, and observable outcomes to expose ambiguous rules before they turn into disputed acceptance decisions.
Read MoreRecognize when spreadsheets need stronger operating controls
A spreadsheet does not need replacement simply because it is important. Evaluate editing rights, rule ownership, reconciliation, and recovery to decide whether stronger controls or a dedicated application are justified.
Read MoreIdentify the process owner before choosing software
Software cannot settle an unresolved question about who owns a business process. Identify decision rights across departments, exceptions, and ongoing operations before comparing products or delegating requirements to a vendor.
Read MoreChoose MVP scope without removing essential safeguards
An MVP should reduce the breadth of an experiment, not remove protections from a real operating workflow. Separate optional convenience from access, data integrity, and recovery requirements before cutting the first release.
Read MoreMap exceptions before designing the happy path
A smooth workflow can hide the decisions that make a service expensive to operate. Map missing data, conflicting updates, cancellations, and recovery ownership before approving the normal path for implementation.
Read MoreInterview users without steering their answers
User interviews can produce confident but misleading answers when questions contain the preferred solution. Use recent events, neutral follow-up questions, and separate evidence notes to learn what people actually need.
Read More