Product Development as a Business Capability

The decision turns on two questions: how differentiated is the commercial requirement, and what is the cost of the gap between what a platform offers and what the business actually needs? If the commercial requirement is standard and the platform can serve it without significant configuration or compromise, the platform is usually the right answer. If the commercial requirement is specific enough that a platform would require extensive modification to meet it, or if the gaps in the platform would constrain the product's commercial performance, building is the more defensible choice. DAM's position is that the build-versus-buy question should be answered before an architecture decision is made, with the commercial requirement as the primary criterion, not the relative cost of licensing versus development at the point of initial procurement.

The right scope for an MVP is whatever is required to test the commercial thesis at the lowest viable cost, no more. This means the MVP is not designed to be feature-complete or to satisfy all stakeholder requirements. It is designed to answer a specific commercial question: will the target user engage with this product at a sufficient rate and depth to validate the revenue model? Everything in the MVP scope should connect to answering that question. Features that would be good to have, features that a business unit requested, and features that improve the experience for users who have already adopted the product all belong in a later phase. Scope discipline at the MVP stage is where most enterprise product programs lose control of their commercial timeline.

More directly than most organizations account for. A subscription product where revenue depends on consistent monthly usage requires a different onboarding architecture and a different approach to the first-use experience than a product sold on a per-transaction basis. A product that needs to support tiered pricing requires the data model and access control architecture to reflect that from the first build cycle. A product where revenue grows through expansion within an account requires the usage data to be structured in a way that makes expansion triggers visible to the commercial team. These are not settings that can be adjusted after the product is built. They are design decisions that need to be made while the architecture is still open, which is why the revenue model is treated as a design constraint from day one in a DAM product engagement.

The most consistent cause is that adoption was treated as a communications or training problem rather than a product design problem. A product that requires behavioral change in its users will only achieve consistent adoption if that change is designed into the product experience, making the new behavior easier than the existing one. Large organizations often solve this problem by adding an adoption program: training sessions, internal communications, usage targets, and manager reporting. These interventions can improve adoption at the margin but cannot substitute for a product that was not designed around how its users actually work. The adoption design work that produces durable usage rates happens at the architecture stage, before the first interface is built.