Lock 8 Logo

As he does in his blog with astonishing frequency, David Cummings last week put his finger on a pervasive problem in startups: complexity of messaging. To cap-off a characteristically well-constructed case for communicating with simplicity, the post concludes with this guidance to operators: “The next time you describe your product, competitive position in the market, or value add, reduce the complexity of the verbiage. Increase the understandability. Make it clear.” Such great advice; and I’ve been thinking about it all week. But, like many things in life, it is easy in theory // difficult in practice. So, I’ve tried here to stand on the shoulders of a giant, and offer 10 tips & tricks that we’ve employed in our own efforts to follow David’s counsel toward clear messaging:

  1. “Fuzzy writing = fuzzy thinking”: My first boss repeatedly used this line to admonish against messaging that lacked crispness. His point: before you put pen to paper, take the time to REALLY think the messaging all the way through. Doing so will materially tighten the output and save time.
  2. Go Solo: For heaven’s sake, don’t group draft. So often sub-scale companies strive for inclusivity and seek to incorporate input from many parties into their messaging. It’s painful for all and rarely produces good results. Many perspectives are absolutely good / needed…but many voices are not. When it comes time to codify the message, have one person own it.
  3. Go Pro: All middle school students allegedly learn to write. So, it stands to reason that even the smallest of startups has the resources to craft its own messaging. But clear, concise, compelling writing is deceptively difficult. There is no shame in outsourcing this responsibility to experts.
  4. Go Pro 2: To further plug the outsourcing model, professional writers are often surprisingly affordable. And, beyond their sheer expertise, outsourced writers bring valuable perspective / objectivity to the task. Finally, the mere act of engaging someone to ghost-write forces real up-front clarity of thought within the company (see point #1 above).
  5. Go Analog: In today’s digital world, even the earliest messaging drafts tend to start on a keyboard. But, with apologies to trees, a piece of scratch-paper can be an invaluable aid to crafting one’s message. Writing down by hand one’s ideas tends to allow for total freedom and enable non-linear thought (which is surprisingly hard to replicate digitally). On the other hand, when one can easily cut and paste with a click of the mouse, it tends to breed more verbiage — frequently at the expense of brevity.
  6. 10–20–30 Rule: In his classic book “The Art of the Start,” Guy Kawasaki promotes an approach to startup pitch-decks that includes a simple rule: “A PowerPoint presentation should have ten slides, last no more than twenty minutes, and contain no font smaller than thirty points.” This is a great forcing mechanism for clear messaging — it really is hard to comply with the 10–20–30 Rule while using a lot of jargon and buzzwords.
  7. 80/20 Writing Rule: Spend 20% of your time on the first draft…and 80% on editing / un-writing. This is likely a terrible strategy for journalists with strict deadlines…but there is no end-date on optimizing company messaging. Take advantage of that fact to let the message marinade and evolve over time.
  8. 80/20 Presentation Rule: A corollary to the rule above is to dedicate 20% of presentation prep time to slide creation, and 80% to nailing the talk-track. Rarely is this rule followed. But, in terms of clarifying the message, it really pays off.
  9. Solving versus Doing: Some of the most jargon-laden company messaging results from trying to explain “what the company does.” Instead, focus on “what problem the company solves.” The Jobs-to-Be-Done framework can help a lot here.
  10. Go Metaphorical: As humans, we like stories and images. They are powerful and we can remember them. These are attributes worth striving for in company messaging. Leveraging metaphors can help reduce the complexity of messaging, while also making it far more appealing. But, a few words of caution: (1) test to ensure the metaphor is truly clear and valid — mixed or inaccurate analogies are actually counterproductive, and (2) unless the business / product actually relates to war or sports, avoid metaphors that use those topics. I’ve made this mistake…just…don’t.

In short: David Cummings was dead-right — in terms of company messaging, make it clear! Hopefully these tips make it a bit easier to do so.

One of the benefits of the SaaS delivery model is that it enables an iterative approach to product development. Because of the relative ease with which software updates can be delivered, SaaS solutions evolve fluidly and organically, with small improvements, enhancements, and fixes introduced often in a seemingly steady stream. But this does not mean that major upgrades are a relic of the past or that big-ticket development initiatives are obsolete. Rather, even with the most thoughtful product planning, time has a way of cruelly revealing ill-advised feature choices, scale-limiting technology decisions, and ever-changing market needs. In this way, each incremental release of new code propels SaaS businesses along a predictable path toward a crucial and somewhat unavoidable question:

Whether to continue building onto an existing solution (with all its pros and cons), or to re-think the whole approach, with the benefit of invaluable knowledge learned over time?

Such initiatives come in many flavors and go by different names, such as: re-platform, major upgrade, re-write / re-build, next-generation development, future proofing, and addressing tech-debt, to name just a few. Nearly all successful software companies contemplate such an effort at some point in their life cycle; and it is a fraught decision with existential ramifications. While the benefits of these types of initiatives can be positively transformative, they also represent significant potential costs and risks (e.g. large investment of time and resources, opportunity costs for projects not pursued, freezing new client sales, brand-damaging disruption and alienation of existing clients, and loss of critically important subscription revenue). Having participated in a number of these major initiatives as an operator over the years, I’ve come to appreciate that these are extremely complex and there are no silver bullets. Likewise, every one of them is unique; and yet, these situations share numerous characteristics and dynamics, with applicable lessons to be learned from each. With that in mind, below are five quick observations and takeaways relating to this common, yet extremely high-stakes, situation.

Note: For simplicity’s sake, I’ve used the term SaaS throughout this article, although these principles apply to any number of modern software delivery models. This raises the important strategic decision of how to utilize cloud services while modernizing the architecture of a SaaS solution. I don’t intend to address that topic here, but will plan to tackle it in a future post.

  1. Strategic Clarity: To quote Simon Sinek, “start with why.” Be very clear on precisely why you are undertaking such a monumental endeavor in the first place. What specific results / benefits do you expect to achieve and how will those benefit your customers and prospects? If you can’t concretely answer these questions and communicate them honestly and with conviction to customers (no spin!), then the whole initiative may warrant re-thinking. Likewise, be very explicit about your strategy, and don’t compromise on it. At a high-level, what is the approach and the thinking behind how you seek to achieve the goals identified above? Tactical and execution questions will arise, but don’t blur them with strategic questions. Moreover, don’t confuse strategic risks (those that are inherent in your strategy and cannot be meaningfully controlled or managed) with actual risks that can and should be mitigated. Once the strategy has been set, focus maniacally on controlling those execution risks that can be actively managed.
  2. Beard-scratchers Welcome!: Projects such as these bring big, messy, strategic decisions that impact all parts of the business. Accordingly, it is important to make plenty of “white-space” in people’s schedules to allow for extended and unbridled debate at all stages of these projects. Moreover, these debates need to include a wide range of constituents with different perspectives. In some ways, this is counter to the “get-done” culture at most small-scale SaaS businesses, where the inclination is more “to do, than to think.” In these companies, we try to protect people’s schedules, in order that they can crank out the important work on their plate. Likewise, we tend to strive for efficiency in our meetings, with tight agendas and a minimization of any wasted time (“let’s get back to actually doing stuff!”). It is critically important to fight this urge and to get in a room and debate. These are almost never “30 minute” decisions; they need to be given the room to breathe and the benefit of many people breathing life into them.
  3. Landing the Rover on Mars: It is paramount that the whole organization understands the long-term product vision as early as possible. The far-reaching vision impacts not only near-term product decisions, but also virtually every supporting operating decision across the entire organization. This will ensure that decisions that are made today at all levels of the organization actually support ultimately arriving at our envisioned destination for the future. And, make no mistake, every seemingly small decision will have a material downstream impact. We’ve used the following metaphor to help drive home the implications of this point: “If you want to land a Rover on Mars…be precise in your trajectory. Because, the distance between here and there is so large that if you are one degree off target…you will wind up on Pluto.”
  4. All-In vs. Modularity: This point refers to the concept of a platform, environment, eco-system, or suite of solutions — terms that SaaS businesses tend to use to describe their product sets. Most SaaS providers contend that customers will derive disproportionately large benefit from holistically adopting all parts of a “platform” in concert, versus cherry-picking one-off products or functional modules. In this way, 1+1+1 should equal 30…not 3. At the other end of this spectrum sits “modularity,” which connotes (among other things) freedom of choice. Specifically, customers can elect to mix best-of-breed products or point solutions to address their business needs. Each of these approaches has strengths and weaknesses; and I’m not here to argue one over the other as being universally superior — as always, context matters. However, it is absolutely worth examining the goal of a given initiative through this lens. Where on this spectrum does your company expect to position its offerings at the successful conclusion of this initiative; and how will you convey value to prospects and customers? Whatever that point is…identify it, embrace it, and own it. So many product and go-to-market decisions will be driven by this decision; and the only truly bad decision is no decision at all.
  5. On-Ramps and Highways vs. Parallel Surface Roads: Because the dangers of negatively impacting current customers with any kind of disruption are so scary, we tend to be risk-averse in these efforts. It can be helpful to compartmentalize these risks with the help of the following metaphor: The current / legacy solution represents surface streets for clients. Those windy, narrow streets get them where they want to go, but the routes are often slow, fuel-inefficient, and require local knowledge. Our revolutionary new solution represents a super-highway — high-speeds, easy navigation, and clear line of site to desired destination. Clients understand the benefits of the highway, and they want to travel on it; but making the cut-over from surface streets can be intimidating and treacherous, so they are reluctant to make the switch. Their concerns can lead us into playing it safe, by minimizing change and simply recreating / replicating existing functionality in the new platform. Don’t succumb to this temptation — doing so is analogous to paving parallel surface streets — ultimately no better and no faster than the existing ones. Second, on-ramps describe how clients gain access to the new solution. SaaS businesses need to provide clients with multiple different “on-ramps” so that clients can choose WHEN, HOW, and HOW FAST they choose to move over and adopt the new solution. Paying close attention and investing heavily in providing many different on-ramps (not just one-time or one-size-fits-all) are the best ways to ensure that all clients ultimately elect to get on the highway.

While these concepts are applicable in many ways, they are just that — concepts. They need to be applied in pragmatic ways that make sense for each unique reality that SaaS businesses face. As stated above, there are no easy answers to solving to these supremely complex issues; but hopefully the tenets above will help folks navigate these major initiatives as they arise.

I wrote in a previous post about defining a SaaS business’ product vision, and in another one about orienting company operations around the needs of key stakeholder groups. Each of those activities plays a role in ensuring alignment and optimization of a company’s limited resources. I’ve since read this post from Josh Schachter which beautifully ties together those and many related ideas. His article “How Teams Can Outperform Using the Startup Ops Pyramid” introduces an excellent model for establishing a shared mission and “unifying any multi-disciplinary team on a single set of goals.” For years, our teams at a wide range of SaaS businesses have been using (and consistently inspecting & adapting) a similar model for this exact purpose. And while there are certainly some distinctions between our two models in terms of terminology and emphasis, my hope today is simply to build upon Josh Schachter’s excellent work.

Specifically, at the top of his Startup Ops Pyramid is the team’s vision. The article cites the very useful metaphor (made famous by former Medtronic CEO Bill George) of vision as true north for a team. It also establishes the key criterion that a vision must be simultaneously “aspirational, yet still relevant to present day.” The article provides some additional nuggets about vision, before moving on to discuss “vision pillars” (which our model would classify as “strategic pillars” (potato, po-TAH-to, as they say)) and other elements of the pyramid. What I want to double-click on here, though, is this crucially important — but maddeningly elusive — task of setting a team’s vision.

The bottom line is: setting a vision is hard. And frustrating. And, if not actively leveraged, commonly not worth the time and energy that goes into creating it. In many people’s minds, it’s right up there with crafting the much-maligned “mission statement” in terms of incurring organizational brain damage or inciting collective eye-rolling. But that doesn’t need to be the case; and I’m hoping the following points can help alleviate some of the pain — because successfully identifying your company’s true north is totally worth the effort.

More than anything else, I’ve observed what makes vision-setting hard is the monolithic and high-stakes nature of it. After all, the whole purpose is to distill the vastness of everything we are as a company and everything we want to become in the future into one statement. One single, pithy, inspiring-but-credible, non-constraining-but-also-non-delusional, universally-relevant-but-narrowly-applicable, not-too-jargon-filled, baby-bear-just-right kind of a statement. In other words, it’s extremely difficult to do, and in many ways is set-up for failure. Why? Because we want our vision / mission to be too many things to too many people and for it to do way too much. We expect the vision to be everything from the words we see on the splash-page of our website, to the opening statement we use in every sales call, to the ethos we use to recruit team-members, to the guidance we consult to set detailed performance metrics, to the all-knowing arbiter for helping us prioritize what features to build in our solution, and countless other tasks for which it is likely ill-equipped.

To battle this, my argument is NOT to grind away at defining and concisely codifying that one, shining true north. Nor is it to better delineate between terms such as vision / mission / strategy (although there are absolutely useful distinctions). Rather, I want to try to expand upon this idea of true north from being one single point of light, and re-imagine it as a whole constellation of separate, but intimately connected and interdependent guide stars, that a company can truly use to light the path forward.

Specifically, if we allow ourselves to temporarily avoid wordsmithing (i.e. forget about the loaded terms “mission” or “vision” and stop worrying about how it sounds!), we can ask and answer a whole series of questions that help us think more holistically about who and what we want to become. The collective output, of these simple but profound exercises can then be referenced as needed by a range of stakeholders. It can also be flexibly leveraged to more precisely fulfill the kinds of organizational needs described above. I call these “existential questions,” and a below are seven of them that we like to use to help create our constellation of true north stars:

1. What impact do we want to have on the world?

2. In a very general sense, what do we want to be as a company when we grow up?

3. What business are we in?

4. What is our product offering today and in its ultimate expression? Why, how, to whom (and against whom) do we sell it?

5. What are we passionate about? What are we good at? What will people pay us for? Where do all three of these things overlap?

6. What does the market think about us? How do we want to be perceived? What stands in the way of getting from the current to desired perception?

7. How do we want to work? What kind of environment do we want to create?

Using Your Constellation:

As I write this, I realize that there are so many more exercises that could be included in the list above. And yet, this seems like plenty for now. Hopefully, I’ve expanded Josh Schacter’s truth north vision from single star into a broad-based constellation of north stars to by which to navigate. The constellation can be referenced in all the ways the variety of stakeholders need: how to present ourselves in an RFP, how to represent ourselves in creating a job description, and how to talk about the product roadmap in a sensible and compelling way, for example. That’s a lot to ask of one, thoughtful, single vision statement.

But, far more important than the series of exercises, is how your organization chooses to view and use the work that comes from them. I have found that the collective output and learning from these types of exercises can offer a “true north constellation” that is at once specific and clear, but also flexible, broadly applicable, and pragmatically actionable — often far more so than a vision statement in a traditional sense. In my experience, this work is equally valuable either as a complement to your company’s existing vision statement, or as an alternative to the challenging task of crafting one.

Still, as we often say, “The hard work starts AFTER the meeting;” and this is absolutely the case in connection to these “existential questions.” Accordingly, I hope to focus a future post on steps to ensure the organization is actualizing the ideals envisioned in these exercises and getting better at doing so every single day.

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.

Are we speaking the same language? Let’s talk.

L8 icon
379 W. Broadway
New York, NY 10012

Contact
©2023 Lock 8 Partners 
|
Privacy Policy
 chevron-down