Breaking Through the Noise as a Software Company
Many small-scale SaaS businesses struggle to manage a challenge that lies at the very core of what it means to be a software company: codifying a bold product idea into a clear and compelling vision, and then translating that vision into a manageable action plan for a team to pursue in a unified, effective, efficient way.
This issue manifests itself in countless ways, but often initially appears as an organization transitions from a single product visionary and developer (commonly one and the same person) to an expanded, multi-person team with increasingly divided responsibilities. That said, companies of all sizes can continue to grapple with this issue for years; and (arguably) every growing company experiences this at some point. I’ve “been in this movie” a number of times, and I currently meet with a lot of companies for which this issue is a consistent cause of pain.
This post explores this concern and shares a few related and tested concepts, in hopes of taking steps to demystify this common business constraint. Specifically, we’ll try to more clearly define and describe a few familiar terms (and perhaps introduce a few news ones), as follows:
Product Vision: What exactly is a Product Vision (“PV”), and why do we need one? A PV clarifies the overall goal or purpose for a product or service. More so than any feature or function ever could, the PV offers a high-level sketch that communicates the essence of a product in a clear, concise manner. It provides a “True North” for anyone entrusted with stewardship over the ongoing development of the product. Without such a still-point, such stewards will always be in danger of getting whipped around by the swirling winds of multiple stakeholders’ wants and needs. Instead, a well-defined PV helps these people make sound decisions about where / how to invest limited development funds and resources — today and in the future.
Product Roadmap: The Product Roadmap (“PR”) is an often overused and misunderstood term in technology companies; it is worth putting a stake in the ground with a brief definition. At a basic level, the PR articulates how a product’s features and capabilities will evolve. As a statement of future intent, the PR inherently contains risk and uncertainty, rather than representing a statement of fact. For future iterations of a product, the PR identifies anticipated timing of general availability, planned areas of development, and the target customers’ needs that are addressed by those initiatives. By definition, the PR represents a prioritization of backlogged ideas / ambitions for how the product should evolve. Anyone associated with a product needs to have some level of understanding of the PR. First, developers need to know what they are expected to build; and internal client champions and services personnel need to have an understanding of the product they will be expected to implement and support (and so on, across every part of the organization).
The PR also facilitates a constructive dialogue between the team and external stakeholders. Product users crave an understanding of how their current wants will be met with near-term enhancements and how well their vendor-partner will anticipate future product needs. These are addressed via a well-constructed PR. In any market, the better a company is at communicating its PR (and then faithfully executing against it), the more attractive they are as a vendor-partner. Note: Although the RM may differ in form and time-horizon when applied in different development environments (e.g. Agile), its value remains high within all of them).
Product Framework: One of the big challenges, of course, is translating the high-level PV into a streamlined PR that:
a. Supports the aspirational vision
b. Makes clients happy,
c. Is commercially viable, and
d. Can be realistically completed by time and resource-constrained teams.
This is where the Product Framework (“PF”) comes into play. The PF is a Rosetta Stone that provides two-way translation between the Product Vision and Product Roadmap. More specifically, the PF is the lens through which we view the world. It helps us break the enormity of the Product Vision into meaningful but digestible parts. Likewise, it allows us to categorize the seemingly infinite and overwhelming number of product ideas (that are vying relentlessly for inclusion on the Product Roadmap) into a manageable set of thematic buckets.
A particularly valuable PF will be of sufficiently high-level of abstract to elevate the prioritization exercise beyond a battle over the relative value of feature / capability categories. Specifically, the PF enables thoughtful, intentional prioritization in support of agreed-upon business goals, and avoids (a) the tyranny of the “features arms-race” and (b) product development driven by “the squeaky wheel.” Thank heavens for the Product Framework.
Guiding Principles: Whereas the Product Framework (and the resulting Product Roadmap) determines “WHAT” gets built in a product, a company’s Guiding Principles govern “HOW” that occurs. This in turn influences the personality, character, or brand essence of a given product / service / solution. A few examples of well-known brands from other industries, and related guiding principles that drive the character of their offerings:
· Wal-Mart: “Everyday low price” drives much of a customer’s experience
· Ritz Carlton: “Genuine care and comfort of guest” is a driving principle
· Zappos: “Delivering WOW through service” is a defining focus
These are examples of characteristics that organizations want their solutions to embody for their valued customers, so much so that they trump considerations about individual product or services features. At companies with strong conviction and commitment to Guiding Principles, they will continuously make decisions about whether or not to build different new sets of functionality, but they will stubbornly avoid developing features that compromise or undermine the agreed-upon Guiding Principles.
Closing: With this post introducing some working definitions for the above terms, I plan to revisit these concepts in follow-up posts. The goal of those future posts will be to further examine some lessons learned in these areas, and offer some tips for producing related, usable artifacts. At the very least, I’m hoping that the above explanations / definitions can help spur productive conversations, that gets teams closer to taming this ever-present challenge.
