This blog recently featured a post that invoked the First Rule of Holes (“Stop Digging!”). That piece had been triggered by some business-planning discussions; and it advocated taking a structured approach when tackling deceptively difficult business questions. In that case, the seemingly innocuous question was “What do you do when it’s not working?” That post offered a framework to assist in the first step of problem-solving — actually identifying the existence of a problem in the first place.
This is part two of that post. It picks up where the last one left off: developing hypotheses to test why something isn’t working. Building on the initial framework, this piece endeavors to share a structure to use in the critical step of diagnosing the source of a business problem.
The “law of holes” was drilled into my head as a kid; and it is sound advice. The problem, of course, is proactively identifying whether and when you are actually digging yourself a hole.
I was recently reminded of this dynamic while visiting with the impressive leadership team of a 40-ish person SaaS company. We had met to discuss a range of topics relating to the life cycles of growing businesses. One person posed a seemingly straightforward question to the group that resulted in an immediate and spirited exchange: “What do you do when it’s not working?”
As a rich discussion unfolded, I remained silently stuck in the subtle, complexities of the question. While the debate whizzed past, I did what I often do when stranded in such situations — start to draw. The graphic below is a more formalized version of my notes and thought process from that session. It’s also an attempt to offer a simple approach to tackling this deceptively tricky question, and potentially others like it that prove surprisingly elusive to wrangle.
In a previous post, I shared observations relating to the process of re-platforming a SaaS solution. I was grateful when a former colleague reached out to comment on that piece. He offered that the term “SaaS” was somewhat limiting in this case, and that the principles in the post applied to any number of modern software delivery models. And, because no good deed goes unpunished, I asked him to guest-write an article that topic. Thankfully, he agreed! Chad Massie is highly qualified to opine on the issues encountered when deciding how to utilize cloud services while modernizing the architecture of a SaaS solution. I’m delighted to share his thoughts on this topic on Made Not Found. Thank you, Chad for the post that follows.
For any business, but especially for those providing software as a service, cloud infrastructure offers a tremendous opportunity to drive organizational value. The question is not if a cloud strategy is appropriate, but rather which strategy to pursue and how to ensure that business and user value drive the decision-making. The five observations below were developed over five years of operating a high volume, high availability, cloud native software platform, and though there are several technical take-aways, the most important lessons are the human ones. Those observations and the related reflections on people and teams are below:
There is no single cloud strategy
In ways that can be both advantageous but also challenging, not every software or business will be best served by the same cloud strategy. This provides great flexibility in terms of timing and investment, but it also signifies that time spent up front posing the essential questions, understanding the needs and clearly defining the desired goals, and establishing the acceptable risk profile will pay considerable dividends (e.g., start with why).
The primary question of whether to “rehost” or “replatform” or “rearchitect” has no obvious answer. Each of these approaches has pros and cons — from a technical perspective, of course, but just as importantly from cultural, operational, and business value angles — and all can offer benefits for your organization. A rehosting strategy can help reduce near-term risk but might slow the upside value for an aging application; rearchitecture can provide a path for addressing major technical debt and modernizing the user experience but brings with it more significant complexity and change that may be more than your business or team is in a position to accommodate. Again, understanding your own context and priorities will help lead you to a better decision for your organization. You might determine that experimenting with an application that has a lower risk profile (e.g., an internal application, a non-mission critical platform) or a specific operation (e.g., disaster recovery) is the path that will ensure long term success, or you might determine that an all-in approach is the way to best serve your customers and inspire your staff.
Cloud is a culture (change)
Processes, organizational structure, and technical strategies that were foundational to success in an on-prem or hosted SaaS operation will not necessarily translate in a true cloud environment. The cloud requires a shift in cultural thinking, and as a result, demands a well-considered change management strategy for your team(s). One common theme is establishing a Devops mindset whereby the members of your various technical teams are involved in the full lifecycle of product delivery and support. Another is fostering an environment of knowledge-sharing and a blamefree ethos. The amount of new learning to be performed and the pace of change in cloud technologies require open communication, collaborative work, and “failing forward.” Further, the culture of learning and partnership requisite to success in the cloud extends beyond technical roles; product, marketing, finance, support, and management positions will all see implications to their work and their team interactions as a result of a cloud-oriented strategy. They must be incorporated into the transition planning and energized by the opportunities every bit as much as the technologists.
Patterns are your friend
Similar to the way software and user experience patterns have emerged over time, there exist many proven cloud architecture and process patterns that can help reduce effort and risk while ensuring security and operational reliability at scale. Whether incorporating elements of Amazon’s well architected framework, pillars of great Azure architecture, or Google’s cloud adoption framework — or something else — make use of these cloud patterns to shorten the time it takes to realize benefit for your organization. As with anything in life, though, an extreme position can limit our perspective, and cloud architecture is no different; it is both a science and an art. The scientific patterns and frameworks should be used to help streamline your architectural approach, but their parameters shouldn’t get in the way of your team’s creativity, the practice of experimentation, and applying their unique contextual knowledge in crafting the most valuable solutions for your business.
Instrument, monitor, and automate
Cloud infrastructure and the technologies that have been developed to support cloud-based software lend themselves extremely well to measurement and instrumentation. The fidelity of this information provides exceptional insight into the operations of your technical platform, in identifying issues proactively, and in understanding user behavior. Additionally, since utilization of a cloud infrastructure eliminates the dependence on physical hardware and enables access to on-demand scale, your strategy should push to automate as much as possible. Besides reducing repetitive efforts, automation will diminish the risk of human error and security exposure, increase overall quality, and help in delivering an optimal experience to your end consumers.
The cloud is constant innovation and reinvention
Advancing a cloud infrastructure strategy is an amazingly exciting journey. The dynamic nature of the landscape forces evolution and thoughtful change. As with any sound technology strategy, it demands attention to maintenance, performance, and reliability, but it also provides for reinvention and innovation in manners that did not exist previously, especially for small and medium sized software businesses. Rather than investing large amounts in original R&D, you could choose to utilize your cloud vendor/partner as your R&D arm, investing your resources in making the most of the innovative assets they bring to market while also providing enormous professional growth opportunities to your team. A cloud architecture gives you much more flexibility and a broader range of strategic options than has been historically available to SaaS companies, allowing you to select an approach that best meets the needs of your business, your team, and your customers.
Though the pathways toward a cloud architecture are now much more well-worn than they were several years ago, each software platform and each business is different. Coupled with the reality that cloud technology is a perpetually changing environment, there are no universal strategic approaches that will guarantee success. However, if you start with the right questions and understanding of the business drivers, build a work and communication plan aligned around strategic goals, and advance a team culture that values learning and collaboration, I believe the lessons above are applicable globally and can help ensure that your organization reaps a cloud strategy’s tremendous benefits.
A previous post on this blog outlined the struggle that many SaaS businesses face in driving a company’s product vision, strategy, design, and execution. That prior post offered some general concepts and terms aimed at demystifying this weighty responsibility, which includes codifying a well-informed product idea into a clear and compelling vision, and then translating that vision into a manageable action plan for a team. For the sake of brevity here, we’ll call those collective efforts “product management.” This post tackles the same topic, but instead examines how organizations evolve and mature in terms of developing product management capabilities as a core SaaS discipline.
Why focus on this topic? First, because product management is really hard; and many companies struggle with it. Second, because virtually every product management organization is trying to improve. And third, because we as humans inevitably want to run before we can walk. Similarly, many organizations naively desire to jump directly from their current-state (whatever that may be) into being a sophisticated, best-in-class product management machine. But it doesn’t work that way; there are no shortcuts. Rather, to be able to run a marathon, we need to commit to lacing up our metaphorical jogging shoes and following an increasingly rigorous training plan, in order to properly prep for race-day.
To be clear, this post does not pretend to be a step-by-step product management training plan. Rather, it intends simply to offer a competency model that captures what we’ve observed across many years and multiple SaaS businesses. Specifically, it lays out a competency framework for thinking about key milestones along an organization’s evolutionary journey in product management. Again, why? Because, although it is helpful to know what “great” looks like, it is also valuable to have a clear vision for what is one step beyond today’s current state. And, because every great journey starts with a single step, let’s get going.
First, we’ll need to agree on a simple premise: the better an organization is at product management, the greater and more positive that function’s impact is on the current and future performance and outcomes of a business. Now, if we were to plot that concept on X and Y axes, it might look something like this:
Setting aside for one moment the wide-ranging skills and capabilities that fall within the general heading of product management, let’s also agree that product management competency can range from very low (poor) to very high (expert), offering two ends of a spectrum. Using the “Maturity / Impact” construct above, it’s fair to state that the very lowest performing product management function has a correspondingly low (or even negative) impact on the related business. One might even say that the impact on the business is one of creating “chaos” (or at least failing to avoid it). Conversely, the most highly evolved product management organizations have a massively positive effect on their companies / products / customers. We’ve observed this to have a “transformational” impact on those same sets of stakeholders. In between these two poles, there are increasingly impactful gradations. We tend to think about it in the following five phases of maturity / evolution, as follows:
Please note: the above is NOT scientific or drawn to any scale. If it were to be drawn to scale, however, I believe the positive impact of Transformational product management capabilities (the last bar of the graph) would be orders of magnitude higher than the Chaotic or even Forming PM capabilities bars. They are simply incomparable in value.
Separately, there is another dimension to all of this; let’s turn our attention to the buckets of activities that comprise the product management function. Although there are countless ways to think about these responsibilities, we like to think about them in four general categories, as follows:
Within and across these four categories, there are a virtually limitless set of activities or tasks for which product management is responsible. The graphic below lays out a representative set of activities; and we think these are some of the more important ones. Because Culture supports and enables the other three categories, we draw it as follows:
Hopefully none of these bulleted items are terribly surprising to anyone who has spent time in a SaaS business. Unfortunately, there is a gap between knowing and doing, so a number of these items are frequently neglected or only nominally completed. In fact, when color-coded for what is comprehensively addressed (WHITE) versus NOT well-covered (GOLD) in a typical small-scale company, the list might look more like this:
Said another way, small-scale SaaS companies’ product management competency can be quite high in some areas, but quite low in others. And while this is arguably interesting in its own right, these activities become much more useful when overlaid with the phases of maturity outlined above. Specifically, performance levels across these categories dictate where an organization falls on the Maturity / Impact graph introduced at the outset. The graphic below identifies how Planning, Execution, Engagement, and Culture look at various phases of Maturity / Impact. This graphic brings it together, as follows:
Hopefully this model is helpful in its own right. But what we have found most valuable are the insights it has helped catalyze within SaaS businesses. I’ll share one of ours here:
Sample Learning: The framework allows managers to more easily and granularly understand how their teams are spending their time. Specifically, it was only when we bucketed activities, surveyed teams, and color-coded activities that we began to pinpoint unhealthy imbalances in allocation of time and resources. What we learned was that growing SaaS businesses we work in tend to be very focused on (and good at) cranking out the most pressing work (Execution). In fact, we’ve seen teams that focus 90% of their time on delivery of the current roadmap. Conversely, these companies tend to vastly under-invest in thoughtful, rigorous Planning, which can account for less than 10% of a product team’s time. Likewise, few resources tend to be directed toward getting consistent, multi-sourced feedback about that work (Engagement). If time and talent are a company’s most valuable resources, we should undoubtedly make sure that we’re using them wisely, through better Planning and Engagement. What this framework also taught us, unfortunately, is that you are only as good as your worst weakness. In other words, even if you are highly evolved in Execution or even Culture, you simply can’t make major strides forward on the Maturity / Impact framework if your Planning and Engagement are holding you back or dragging you down.
Having said all of the above, the looming question remains — what can product management organizations do to improve? In other words, how can we jump to the right on this Maturity / Impact graph? And, more tangibly, what tools or exercises can we implement to help get us there? Having now introduced this framework, it’s my plan to go into some of these tactics and tools in future post here on Made Not Found.
Thank you: I’d like to acknowledge and thank my good friend and former colleague Paul Miller for his contributions to this post. Paul has a clear, disciplined, creative product mind; and his thoughts shaped much of the above. It’s been fun noodling these ideas over the years with Paul; and he has been an invaluable collaborator in our shared and never-ending effort to get better at product management.
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:
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:
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.