"The measure of who we are is what we do with what we have." — Vince Lombardi
An analysis of the service's design and feature set is the final stage of the discovery process — and deliberately so. Understanding the actual software to be designed, redesigned, or transitioned can only begin after all other due diligence has been collected and analyzed. The UI, UX, features, and functionality must be evaluated against the backdrop of budget, stakeholders, resources, business model, compliance requirements, target market, and strategic goals. In that order.
The success or failure of a SaaS service is never the product of the technical brilliance of its design. SaaS functionality works when it aligns with the team supporting and selling it — and it fails, reliably, when the development team embarks on blind feature initiatives disconnected from real user need.
Less is more. Developer creep — the tendency for features to multiply beyond any strategic intention — is the bane of SaaS products. When we migrated MediaTracking to a new SaaS platform, we eliminated more than 50% of the landing pages and countless features that nobody knew existed or knew how to use. The majority of customer support content was eliminated because the remaining features were almost entirely intuitive.
Moving to SaaS is a strategic opportunity to realign the product with the value propositions your end users actually care about. Part of that alignment includes a plan for future features. The POS software we migrated had no integration with accounting software, yet over 90% of the install base used QuickBooks. The roadmap included a plan for building that API bridge — not as an afterthought, but as a defined development milestone.
Feature-Driven Development Framework
◆ Develop the overall model. What is the complete conceptual picture of the service? ◆ Create the feature list. Prioritized, validated against user need, and tied to business goals. ◆ Plan by feature. Break the roadmap into feature-driven milestones, not just time-based sprints. ◆ Design by feature. Let each feature's requirements drive the design decisions for that component. ◆ Build by feature. Develop, test, and ship one complete feature at a time — not partial implementations across many.
Part Ii
Value Analysis Chapters 17–26
With stakeholder input in hand, the work shifts to interrogating the value the service can deliver — and to whom. This section maps the commercial, legal, and competitive landscape before any architecture is committed.