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.
I plan to use this blog to share my thoughts and perspective on growing SaaS businesses and on building successful organizations in general. With that in mind, I thought I’d use this inaugural post to offer a bit of background about me, beyond what can be gleaned from LinkedIn and other high-gloss media. I’ll start with just a bit of personal back-story and then fast-forward to some of what I’ve learned over the past 24 months.
Back-Story: I’ve always loved teams: playing on them, cheering them, coaching them, and always learning from them. And more recently: building, leading, and continuing to evolve through them. Over the years, I observed that the best teams consistently combine two seemingly opposing competencies: First, they clearly articulate their goals and relentlessly pursue them with unity and conviction. Great teams operate efficiently and effectively, and often simply “out-execute” their competition. They do so by leveraging shared principles, well-understood operating norms, and deep experiential understanding of the opportunities and challenges they face together. On the other hand, great teams also possess the humility, introspection, and courage to adapt and change however necessary within dynamic environments and in response to inevitable setbacks. These concepts were deeply ingrained in me by a few legendary coaches, by whom I was immensely fortunate to be mentored. These people had a profound impact on my world-view; and their ideas are foundational to Lock 8’s approach to thoughtfully and consistently building successful organizations.
Fast-Forward X Years: When BoardEffect was acquired at the end of 2016, I assumed I would take a few months to transition-out and rest-up, and then do another round somewhere as a “hired software executive.” I’d been a CEO twice and a President / Managing Director / EVP Operations twice; and I loved leading growth-stage SaaS businesses. Eighteen years had flown by, and these experiences had been transformative for me personally, professionally, and developmentally. It seemed to make complete sense just to “hit replay.”
But I didn’t end-up following that familiar path into my next operating role. Instead, I’ve been on a journey since then, exploring new ways to leverage my love of operations and organizations. This exploration has ultimately led to the founding of Lock 8 Partners, a platform for investing in and optimizing the performance of small-scale SaaS businesses. I am completely energized by this next leg of my journey; and this is a brief synopsis of how I arrived at this point.
After ninety days of amicable transition, I left employment with BoardEffect’s acquirer and promptly became immersed in a number of long-deferred pet projects. As expected, I soon missed my true passion of building teams and businesses; and by July 2017, I was itching to get back into the swing of growing companies. Without a full-time role and company for which I had the requisite level of excitement, I took on a number of part-time projects with a few private equity firms. These included strategic consulting engagements, executive coaching stints, board roles, and operating assessments in connection to prospective new investments. Although these projects were stimulating and challenging, I realized by year’s end that I wanted something with more continuity. So, I committed to spending four days a week in an Executive Chair role at one of the companies with which I had been consulting; and it was fun to be fully-engaged again. I loved helping the team think through how best to unlock the significant potential of that business; and I was completely engrossed in that effort throughout the first half of 2018 (full disclosure, I remain on a more limited basis).
It was during this time and through these collective experiences that I was struck by a number of observations; and these eventually evolved into the foundational ideas behind Lock 8 Partners. To dig into those ideas, please check out Part 2 of this post here.
As I shared in my initial post for this blog, my decision to start Lock 8 Partners was driven by some long-held views, along with a number of more recent experiences and observations. This post picks up on the latter, and attempts to lay out some of the thinking behind founding this business. Specifically, the following observations and takeaways have been central to Lock 8’s strategy and approach.
The more I investigated these and other questions, the more urgency and energy I felt around answering them. As I have sought to do so over recent months, I have gained ever-increasing conviction about this as an investment model; and I believe a unique value-generating opportunity exists at this moment and juncture.
I plan to dedicate many future posts to further outlining these ideas, describing my efforts to understand them, relating their practical application, documenting my experiences in this pursuit, and sharing lessons learned along the way. I hope these will be helpful to all readers, but most specifically for operators who are working tirelessly to build successful SaaS businesses.
Thanks for reading and please come back for future posts.
At Lock 8, we think and talk a lot about operations. Which raises a valid question: what do we actually mean when we use that word “operations?”
Like most words, operations can mean a lot of things to a lot of people. The Miriam-Webster Dictionary defines it as: “performance of a practical work or of something involving the practical application of principles or processes.” I like the pragmatism of this, although it’s a bit sterile and lacks the necessary business context for use here. Separately, BusinessDictionary.com offers the following: “Operations transform resource or data inputs into desired goods, services, or results, and create and deliver value to the customers.” Again, really helpful, but a bit too theoretical to be really valuable.
Before going any further, allow me to inject what we DO NOT intend when we talk about operations (or, at least, we do not intend in any exclusive, strict, or limiting way):
Rather, when we use “operations” in the context of small-scale B2B SaaS businesses, it encompasses all of the above, and more. In fact, it represents virtually all of the complex and interrelated activities necessary to build and grow a sustainable business. Which raises another legitimate question: how can you wrap your arms and brain around something so vast and impactful? While I think that is a great question to discuss over a coffee or beer, I’ll take a crack, by offering a framework centered around a company’s stakeholders.
Very broadly speaking, many SaaS company’s stakeholders can be broken into four categories, as follows:
For me, operations encompasses all strategies / tactics / initiatives / projects / tasks that are focused on, and fall within, any of these stakeholder buckets (Market, Client, Team, and Owners…with a few caveats and qualifiers around the last group). Before the objections rain down, I’ll try to explain:
Under this model, operations would include: identifying a company’s target customer segment, articulating its value proposition, codifying its competitive positioning, establishing its packaging and pricing, defining its go-to-market strategy, scaling its selling motion, and much, much more (Bucket 1: Market).
Operations would also include: deeply studying the problems target clients are trying to solve, designing and developing a solution to address those needs, defining and delivering against a roadmap that fulfills that solution vision, mapping the journey organizations travel as they endeavor to resolve business challenges, provisioning a set of experiences that enable and augment a given solution, and much, much more (Bucket 2: Clients).
And operations would cover all of the necessary people-related needs associated with getting the right people on the bus, into the right seats, headed in the right direction, excited for the journey, and helping to power that vehicle toward a shared destination (Bucket 3: Team).
And finally, this definition would cover establishing appropriate company goals, implementing systems to monitor performance, and fostering processes to inspect and adapt to environmental changes…all in support of reaching financial milestones (Bucket 4: Owners). That being said, I consider the Owner Bucket to be different from the others in two material ways: (1) Far more so than any of the others, this group of stakeholders is focused on outputs (results, outcomes, retrospective measurements) versus inputs (sales pipeline, product backlog, key hires, etc.). (2) The owners are arguably secondarily impacted by an organization’s operations, whereas the other stakeholders are either the producers or the immediate recipients of every operating action. More on this interrelationship in a future post.
Clearly this post only begins to scratch the surface on the Grand Canyon-esque topic of company operations. But hopefully it has provided at least enough background to demystify the general scope and scale of what we are referring to when we use the term “operations” in connection to growing SaaS businesses.
(1) https://www.merriam-webster.com/dictionary/operation
(2) http://www.businessdictionary.com/definition/operations.html
