Within our portfolio’s cohort of SaaS CEOs, budgeting consistently ranks among the most challenging aspects of their jobs. This led to a recent post on this blog which argued in favor of now as a good time of year for SaaS businesses to examine previously un-budgeted expense items. That prior piece prompted a broader review of general budgeting processes, and provided a reminder of another simple but effective tip to help make budgeting less painful for SaaS CEOs.
First, let’s take a minute to recap why budgets are important for small-scale SaaS businesses, even those that are bootstrapped or that operate without a formalized board of directors. Most importantly, budgets serve as sense-makers for businesses. They quantify in specific terms whatever qualitative plans exist for the business. We generally codify initiatives and objectives in an annual Strategic Operating Plan, but these artifacts go by many names and can range widely in form. In whatever form your plan exists, a budget double-checks whether that plan is feasible and properly funded. It also helps enforce alignment of resources across the team and around that plan. Finally, budgets help businesses translate their inevitable idiosyncrasies into a set of universally understood measures (e.g., revenue, expenses, Rule of 40, etc.). In short: budgets = good. The problem is that budgets can be excruciatingly difficult to nail down, particularly for CEOs who may not have deep financial training (which, in the world of small-scale SaaS, is more the rule than the exception). For those typical CEOs, a persona-based approach to budgeting can help.
Wait…personas?! Aren’t those what our Marketing team uses to identify ideal customer profiles? Well…yes…but they can also help crystallize roles relating to the budget process. Specifically, no matter the composition of your team, someone will need to fill the following roles / personas in the budgeting process:
1. The Leader: This person is running point on the entire budgeting process, making sure that the right people are involved in the right ways at the right times. Although this has some tactical project management aspects to it, the CEO is best situated in small-scale SaaS organizations to serve in this role as the budgeting Leader. This is also the person who ultimately has last say on the numbers.
2. The Sensei: This person is a step removed from the budgeting activities and can provide a broader perspective about both the budget process and the actual work product. This person should offer a top-down view on what “Good” looks like — both in terms of the budget output itself, as well as how a given year’s budget supports the multi-year narrative of a company’s financial story. The Sensei is often a board member(s), but it doesn’t need to be. In particularly small SaaS businesses, this might reasonably be an outside advisor, accountant, or consultant.
3. The Model Master: This person is responsible for building, maintaining, and ensuring the accuracy of financial spreadsheet model that usually serves as the backbone of a budget. This person “owns” the (typically) Excel files and builds bottoms-up revenue and expense models. This often takes the form of a “three statement model” which adds a balance sheet and cash-flow statement to the omnipresent profit & loss statement. This Model Master is usually someone in a Finance role, but it can also be an outsourced expert who assists smaller businesses.
4. The Historian: This person has valuable institutional memory. The Historian provides context and empirical data from the past to inform future-looking forecasts. This is a lot more about subtle nuances in the business (e.g., sector seasonality, observed customer payment trends over time, sales cycle statistics) than it is about the headline numbers of a budget. This person is rarely the loudest voice at the table; but their voice is one that should be carefully considered.
5. The Water Carrier: This person is responsible for making material parts of the budget come to fruition. The Water Carrier is also the person / people who carry the quota that will turn the plan into reality (usually in the form of sales and (eventually) revenue). Unsurprisingly, the Water Carriers inject a dose of reality to budgets, particularly when The Leader and the Sensei get overly optimistic / ambitious. This person is usually the head(s) of Sales and Marketing, but can vary across different roles depending on the business model. Unlike other personas mentioned above, this person is almost never a consultant or part-time team-member.
We’ve observed that each one of these personas plays a critical role in successful budgeting processes. If even one of them is missing, it can throw-off the process and drive imbalances and gaps. Importantly, this does NOT mean that there needs to be exactly one person for each of these personas. In smaller companies one person may end up filling two or more of the roles outlined above. For instance, the CEO is often not only the Leader, but also the Historian. This tends to work just fine. The only thing to really avoid is violating the so-called Ghostbuster Rule (“…Don’t cross the streams!!”). Specifically, it’s quite problematic to have one role “moonlight” into someone else’s domain. The prototypical example is the CEO who decides that they want to suddenly dip into and out of the model when the mood strikes them. Don’t do that…it would be bad.
The Ghostbuster Rule
I’ll close with one last framework that can be quite valuable in the budgeting process: RACI chart (R = Responsible / A = Accountable / C = Consulted / I = Informed) can be great for clarifying which position in the org is responsible for what. Hopefully the example below is self-explanatory.
Sample RACI Chart for Budgeting Process
As valuable as the RACI is, though, we’ve observed that its utility is limited unless specific conditions are met. Rather, we find that it’s important to nail the personas above, before a RACI makes much sense to anyone.
In sum, personas aren’t just for Marketing anymore…they can definitely help make budgeting less challenging for all.
Budgets Again // aka: Personas — Not Just for Marketing Anymore was originally published in Made Not Found on Medium, where people are continuing the conversation by highlighting and responding to this story.
“Digital transformation is a foundational change in how an organization delivers value to its customers.” -CIO
“Digital transformation is the process of using digital technologies to create new — or modify existing — business processes, culture, and customer experiences to meet changing business and market requirements.” -Salesforce
“The essence of digital transformation is to become a data-driven organization, ensuring that key decisions, actions, and processes are strongly influenced by data-driven insights, rather than by human intuition.” -Harvard Business Review.
Digital transformation is clearly a hot topic that is top of mind for many business leaders. But for small-scale SaaS businesses, digital transformation can feel like something foreign that “doesn’t really happen here.” Maybe this is because the topic is often portrayed as being unimaginably massive in its scope and implications (per the above quotes); whereas growth businesses must focus near-term. There’s also a “feast or famine” aspect to this depiction; it implies that digital transformation is best suited to either (1) old-school industries with a pressing need to modernize-or-die (the “famine” camp), or (2) highly capitalized, bleeding-edge tech firms pursuing reality-bending innovations (the “feast” cohort). Neither is typically the case in small-scale SaaS businesses, nor is this positioning particularly helpful. Rather, we observe digital transformation within small software companies as taking place one step at a time; and it helps to avoid overthinking it. In this way, digital transformation looks less like otherworldly “foundational change” and more like workflow automation that is pragmatic, targeted, and high-impact. Below are some simple examples from the real-world of Lock 8’s portfolio companies, followed by a few takeaways from these cases.
Marketing and Sales:
Product and Client Success:
These examples help illustrate a few key takeaways related to digital transformation. First, purists would likely argue that the above are all pedestrian / tactical in nature; and they don’t truly represent digital transformation. Fine — potato // po-tah-to. As long as they contribute to meaningful advances in our ability to execute, we don’t care what they are called. Second, tackling such minor improvements is habit-forming. We’ve found that implementing each of these small improvements tends to reveal other worthwhile processes that can be enhanced with minor automation. Third, every aspect of the business is a candidate for such project-lets. The examples above focus on a few departments, but we’ve seen a focus on Sales and Marketing (for example) very quickly shed light on potential workflow changes in Finance, HR, and other parts of the business. And, finally, we’ve found this works best when everyone is invited to play in this game. There may be one person who is particularly talented in business systems — and that person can lead execution — but process improvement ideas need to come from anywhere and everywhere within the org.
Just as every great journey begins with a single step, the road to digital transformation starts with some simple workflow automation — don’t overthink it.
I recently wrote that business dashboards are instruments of control. That observation and the related post, while hopefully helpful, made some general assumptions in discussing dashboards. So, this post takes a crack at addressing an ongoing open point about the existential nature of dashboards: what exactly is their purpose?
Although Stephen Few provides an excellent definition, it leaves room to debate dashboards’ ultimate objective.
Definition: A dashboard is a visual display of the most important information needed to achieve one or more objectives; consolidated and arranged on a single screen so the information can be monitored at a glance. — Stephen Few
Our observation is that the primary purpose of most dashboard initiatives lies somewhere between two general approaches, which can be loosely described as Reporting on one end of a spectrum, and Analytics on the other. The problem many operators face is that their efforts can wind-up betwixt and between the two, often without even realizing it. These two poles offer useful guardrails when considering the objective of any dashboard initiative; and examining and choosing between them helps to clarify many aspects of that dashboard. This kind of clarity, in turn, can help align and ultimately exceed stakeholder expectations.
Five seemingly simple (but deceptively challenging) questions offer a good start toward getting people on the same page:
Although they’re a good start, these questions can admittedly be a bit opaque for practical application. To make them more actionable, we expanded the questions into a “quasi-diagnostic” table. This table captures attributes and examples of each approach, to help leaders identify and intentionally choose how best to prioritize and proceed.
Identifying these characteristics and having open conversations about each can certainly de-mystify the purpose of dashboards and put an organization in a better position to optimize its time and resources.
A few caveats / qualifiers / comments about the above:
In closing, it seems worth following-up with one of my favorite go-to questions: So what? Why does the debate about dashboards’ purpose even matter?! Quite simply, intentionality matters when it comes to metrics measurement. Contrary to popular lore, it’s not so much that “what gets measured gets managed;” Danny Buerkli does a great job debunking that familiar trope here. Rather, as Buerkli succinctly argues, “Not everything that matters can be measured. Not everything that we can measure matters.” So true. And because sub-scale SaaS businesses operate in a world of big dreams but small teams, focus is our friend. Like any other product or service, dashboards should have a clear approach, objective, and target stakeholder…lest they lose their incisiveness and value. So, when considering dashboards, as with all things related to business building — choose wisely and with intent.
I’ll admit that I love a good dashboard. As an aid to SaaS operators seeking to optimize business performance, dashboards can be invaluable.[1] Stephen Few defined a dashboard as, “a visual display of the most important information needed to achieve one or more objectives; consolidated and arranged on a single screen so the information can be monitored at a glance.” This is a useful definition that makes clear: dashboards are instruments of control. Specifically, just as dashboards within vehicles aid in the controlled navigation of those machines, company dashboards help leaders drive organizations forward while controlling speed, direction, and business health. And yet…the irony of dashboards is that before advancing any aspects of a business, sacrifices must first be made in the very same areas that leaders seek to optimize. To go fast, you must first go slow. To go far, start with steps backward. To increase control, make a conscious decision to loosen oversight.
With these contradictions in mind, this post strives to flash a warning light (see what I did there?) by dispelling any illusions leaders may have about scoring easy wins with dashboards. Rather, it introduces some questions to ponder and detours to explore when considering dashboard initiatives. Hopefully these will help folks achieve the goal of getting past the entry-ramps and using dashboards to confidently drive the business forward in the fast lane.
Control: This is What Democracy Looks Like? Advocates of dashboards sometimes tout them as nobly delivering democratization of data. But do dashboards inherently reinforce the notion of one person, one vote? Not necessarily (the term “executive dashboard” seems to succinctly refute this point). Rather, a key question to be answered early in a dashboarding effort centers around data roles, rights, and privileges. Who gets access to what data? Is the dashboard’s audience the CEO? The Leadership Team? Every team member within a business (including / excluding contractors and consultants)? Should there be a curated / filtered set of data for each? Oh, and, what about the board of directors?
A related question centers on how dashboard information is consumed — on a push or pull basis? Purists might argue that dashboard users should be able to “pull” information. That is, they should be able to access what they want, when they want it, and manipulate the information to suit their needs. The problem, of course, is that this is horribly inefficient and variable — we humans rarely know what we want until someone presents it to us as a solution to our needs. That view supports the position of what I call “curators” who believe dashboards are best served up on a push basis. In an extreme version of this model, some analyst-type packages up KPI’s into a report and shares it with a defined set of stakeholders on an agreed-upon cadence. This approach is certainly efficient / prescriptive, but not at all a beacon of data democracy.
My own experience here is that the middle is marvelous. Dashboard information is most valuable when shared broadly with a large number of stakeholders and with minimal access constraints. But the dashboard should also be structured and streamlined, not just a filtered database that can be used to spin-up infinite ad-hoc reports (after all: if everything is important, then nothing is). Finally, regularly scheduled all-hands reviews of the dashboard by company leaders are key to offering commentary and context. This helps provide all stakeholders with a clear understanding of “what matters, how we’re doing in those areas, and what each of us can do about it.” In this way, leaders can absolutely gain more control over their business through dashboards. But they must first be prepared to loosen the reigns on potentially sensitive data and to make themselves vulnerable by sharing it (in good times and bad). I’d argue this approach doesn’t represent a pure (data) democracy, but perhaps it is more like a high-functioning (information) republic.
Speed: Slow is Smooth, and Smooth is Fast: This useful adage from the Navy SEALs has been widely analyzed (e.g. here, here, and here). The general gist is that “the best way to move fast in a professional setting is to take your time, slow down, and do the job right.” This is particularly prescient in connection to implementing business dashboards. As leaders, we want dashboards to serve as an accelerant: to provide early alerts about deviations versus plan, to streamline our decision-making, and to speed the pace of collective results. But…to go fast, we need to start slow. A big-bang approach simply doesn’t work when creating dashboards. Never have I seen a version 1.0 dashboard that was worth a darn. In fact, “if you move too quickly, you bump and bounce and veer from that path because you are frantic, trying to do too many things at once.” Rather, a deliberate and iterative approach to creating dashboards allows leaders to test, learn, adapt, and develop a dashboard that truly serves the needs of the business — over time.
A corollary to leaders’ “need for speed,” is the desire to automate the updating of dashboards. Like a scene from Minority Report, the dashboards in our imaginations should miraculously and effortlessly pipe future-illuminating intelligence directly to our brains on a continuous loop. It’s a compelling vision; and automated updates to dashboards are totally doable — eventually. But a fair degree of manual work is necessary to get a dashboard stood-up. Manual data-entry (the antithesis of tech-enabled efficiency) is often required at the outset of a project, particularly in the early iterations described above. Even after graduating from data-entry, labor is needed to enable efficient and error-free data feeds from different company systems. It. Just. Takes. Time.
In my view, balance is helpful in navigating the tension between slow and fast. Having botched overly ambitious dashboard initiatives, I’ve learned to start small and slow. It’s wise to avoid throwing out an otherwise valuable metric, simply because it is hard to collect — report what matters to the business, even if it requires manual data entry. Conversely, don’t prioritize the automation of data collection early in a dashboarding effort. Doing so can mean “letting the great be the enemy of the good;” and technical glitches have killed countless promising projects. One of my all-time favorite dashboards (a snippet of which is included below) took 18 months to get right. Initial versions were brutally tedious to update — manually. And even in its prime, it was never visually impressive. But, by taking our time, we eventually created an astonishingly valuable tool that helped accelerate the business.
Horizon: Is Real-Time Really the Best-Time? Another common hope among leaders is for dashboards to help predict the future. This translates into wanting to (a) report the most up-to-date information and (b) measure that information in shorter and shorter chunks of time — by month, week, day, hour, and even by the minute. This works well for many metrics, where recency really matters. For SaaS businesses, such metrics might include website visitors, numbers of qualified leads, product usage metrics, or volumes of support tickets.
But other metrics evolve on a slower cadence; and measuring them over short time horizons is less helpful. As a correlate, I’m reminded of the recommended method for taking one’s pulse: top medical organizations advise counting someone’s pulse over a 60 second span. Although it would be a lot more efficient to measure someone’s pulse for only 2 seconds and then multiply the result by 30…that would give a far less accurate reading. Similarly, many metrics in SaaS businesses require measurement over a longer period, lest the results be useless or misleading. This is particularly true in enterprise businesses selling large dollar subscriptions over long sales cycles. In such cases, one week’s worth of data can have very limited utility; rather, we need to see data over a quarter or even multiple quarters. Examples of these longer-lead metrics include: sales and marketing conversion rates, contracted new bookings performance, measuring execution against hiring plans, or quantifying employee engagement. All of these tend to take a long time to materialize and are inherently “lumpy” in nature.
Where this can lead to dashboard-related trouble is when we try to measure all metrics on a uniform cadence over consistent time horizons. Rather, leaders need to approach dashboard projects with realistic views on just how real-time their measurements should be…and apply time horizons unevenly across different metrics.
To further complicate this issue, today’s results are often best interpreted by looking backward in time. This is challenging for many reasons. First, we often don’t have access to good historical data, which is commonly the motivating factor behind the dashboard project in the first place. Looking backward in this way also contradicts every instinct of the future-focused leader who has undertaken a dashboard project for the stated purpose of more proactively looking ahead. While real-time data is certainly appealing, successful dashboard efforts must also consider both current and past data over long time-horizons.
Conclusion: In sum, dashboards can yield valuable results for businesses and offer great benefits to thoughtful business leaders. Specifically, they can increase the control, speed, and foresight with which the business operates. But none of these benefits comes without a cost. And that price is often paid in the form of leaders first making sacrifices, or investing time and resources, in the very same aspects of the business that they wish to ultimately optimize.
Footnote:
[1] Dashboards are also imperfect and highly variable, as argued well here and here.
The television series Undercover Boss has been a guilty pleasure of mine for years. Now entering its eleventh season, the show features “high-level corporate execs (who) leave the comfort of their offices and secretly take low-level jobs within their companies to find out how things really work and what their employees truly think of them.” For cringe-worthy viewing, this one totally hits home for me.
But I also like the show’s more serious theme of “walking a mile in someone else’s shoes” in order to deeply understand that person’s experience. At Lock 8, we’ve adapted this concept to help provide insight into a key focus area for small-scale SaaS businesses. Whereas Undercover Boss leverages this approach to offer candid employee-level views into the internal workings of companies, we hope to shine a light on the experience a customer has when evaluating, selecting, and adopting a B2B software solution.
On the surface, this is a straightforward endeavor, involving a few simple steps:
Simple enough, right? Not really. Like so many things, this is easy to do poorly, and extremely difficult to do well. To help make it easier, this post will share a few tips relating to each of these deceptively challenging steps.
1. Pretend You Are a Prospect: At its most basic level, this is a role-playing exercise, so it’s absolutely critical to play your role well. This may be relatively easy for the undercover bosses referenced above (they get a cover legend and a disguise; and they go), but it is more complicated to get inside the mind(s) of a purchasing committee for a large and complex corporate enterprise. We’ve learned that it is definitely worth investing the time and effort to make it real: have a dossier, real personas, real business problems you’re solving for, deadlines, budget constraints, and even political motivations. Even go so far as to designate a few people to play different decision-maker roles. Balance the company profiles to reflect your current (vertical) targets, your buyer personas spectrum and the maturity of organization using your solution. Marketing absolutely should help develop these resources. Here’s a snapshot of just part of a dossier created by a portfolio company that recently executed such an initiative.
An additional point about this step: BE OPEN! Unlike the undercover bosses, for whom secrecy is paramount, this should NOT be a clandestine endeavor. The reality in software companies is that everyone somehow touches the customer experience. Likewise, our experience is that people in early-stage SaaS business are all operating in good faith, so there is no need to trick anyone or attempt to trip them up. Rather, everyone needs to know you’re undertaking such a journey; and each functional area needs to be part of the process. Now…you may need to make the case: why it’s important; why we need to get it right; who’s involved; what we’ll be doing; how we’ll share feedback. But these are all further arguments for doing this out in the open. Equally important: everyone at the company should hear later what was discovered, and to view the information as a learning opportunity, not a judgement. Nothing makes people more nervous than being excluded from understanding what’s happening behind the scenes or feeling like this is a test.
2. Go Through the Steps: Uh…what steps? Whereas most businesses have established a sales process with related stages and activities, these usually assume a company-centric approach, and overwhelmingly ignore the customer perspective. Customers’ motivations / activities / dynamics are effectively infinite, so identifying their purchasing steps can be paralyzingly complex. To simplify, we like to organize our efforts around “major stages” of the customer’s lifespan with a software solution. Although every product / system / technology is unique, there is a relatively small number of macro-phases on the customer journey; and these are generally consistent across different solutions. The purpose of the mental model and accompanying graphic below is to align perspectives, offer a shared vocabulary, and provide structure to the exercise.
On the principle that a picture is worth a thousand words, I’ll hope this graphic is self-explanatory. In summary, as we engage in countless customer “buying” and “owning” activities, and we organize them into these six phases: (1) awareness, (2) evaluation, (3) decision, (4) on-boarding, (5) use, and (6) advocacy. One note of caution: for complex solutions, this may end up being a grueling multi-month process. It’s important to know what you are signing up for in advance…and what your customers are going through to buy / use your products.
3. Record Your Experiences: A disciplined collection of notes will generate consistency of insight and evaluation. With more than one person involved the experience, it’s important to provide a consistent way to gather intel and feedback. That said, this doesn’t require over-thinking; and a simple note template suffices. We like an “Experience and Expectation” framework (“what did I expect?” and “what did I experience?”) to structure things. Then, just codify the experience in a linear way — capture in detail and in chronological order what happened and how it impacted the buying / owning processes outlined above.
4. Articulate the Ideal: It’s nearly impossible to simply dream up the ideal client experience, just like it is unheard of to nail product-market-fit on version 1.0 of a solution. Instead, it pays to inspect and adapt. Thankfully, the early steps of this exercise, and the current-state baseline they provide, offer an awesome foundation from which to iterate toward a vastly enhanced client experience. As a result, this step can be as simple as revisiting every step along the journey and answering the following question: “what would have made this much better?” In the best case, this can lead to a wholesale re-thinking of the journey; at a minimum, it will radically improve the existing steps of the experience.
5. Identify gaps; build a plan: For the activators in the crowd, this is the payoff where you can begin to implement necessary improvements. But be careful about succumbing to temptation. It is alluring to focus energy on an ad hoc basis to address the low hanging fruit that can be fixed easily. The problem is that this approach can break any number of existing processes that — although they may be sub-optimal — generally work today in the context of the current approach. So be careful about what you choose to “fix” as a one-off — it could just break other areas of your process. Although it requires more patience and offers delayed gratification, an orchestrated program overhaul will undoubtedly yield more substantive improvement of the overall client experience. Make a plan and take your time in executing it. Our experience is that the “customer experience re-engineering” project to come out of this exercise may take months or even years to implement.
As with most pressing, cross-company business issues, initiatives like creating an awesome CX Journey can take on a life of their own. Proceed with caution here; ensure that anything and everything you chose to do ties back to your overarching business needs. Such an effort must involve more than just the bosses; and there is no need to go undercover — doing so will allow companies to walk in their customers’ shoes…a journey well worth taking.
A previous post on this blog shared observations about high-stakes SaaS product development initiatives; and a follow-on piece took a deeper dive into setting related cloud services strategies. Together they focused on considerations when undertaking major SaaS product initiatives (such as re-platforming projects, new user interface introductions, infrastructure changes, functionality expansions, code re-writes, and others).
Although this post builds on those prior pieces, it steps away from the product side of things. Instead, it examines a wide range of critical, but often overlooked, “other stuff” needed to successfully introduce meaningful product changes to customers. Borrowing from the world of project management, we’ll broadly call this topic operational readiness. The harsh reality is that even a well-executed product development initiative can be greatly undermined by inadequate operational readiness. And this is often where many SaaS companies falter, particularly small-scale businesses without mature systems and processes. With that in mind, here are ten quick lessons learned and five “non-product” questions / exercises that can help organizations manage major product change initiatives.
LESSONS LEARNED:
QUESTIONS / EXERCISES:
1. What are our “big rocks” of operational readiness?
This deceptively simple question forces companies to consider all the aspects of their offering that directly or indirectly impact how customers experience their software solution. Although there is a wide range, just a few of the usual suspects on this list include:
2. Who benefits from this project and how so?
Again, this one seems simple but warrants focused attention. The truth is that big product initiatives can take on a life of their own and cloud our understanding of their true purpose and benefit. It helps to think of each stakeholder group (e.g. customers, prospects, partners, internal team members, financial stakeholders) and even sub-sets of users (admins, super-users, casual users, executives). Then, lay-out the tangible benefit each group will derive from the initiative. These might include: a shorter learning-curve (for customers), ease of support or ability to code more efficiently (internal team), or less resource intensive implementation cycle (multiple beneficiaries, including financial stakeholders). We better have good answers for each stakeholder, or else it is going to be hard to justify to them the inevitable cost / effort it will require to adopt the proposed changes (aka: the “pain-of-change”).
3. What are the situation-specific complexities to consider?
Complexities reflect the unique nuances of each product and user-base. These are the characteristics of your business that will largely define how the company must prepare to support impending product changes. Examples of these include:
4. What are the guiding principles to be upheld?
Like any set of principles, these should represent the “non-negotiable” commitments. These may be commitments to customers or to your own organization; and they may be tacit or openly communicated. In any case, what is most important is that they are not open to compromise. Some hypothetical examples of these might be:
5. What are the operating decisions to be made?
All of the questions / considerations above play a role in organizational readiness; and companies must ask and answer a number of pragmatic questions. A few of the usual suspects tend to be:
In sum, change is hard. Operational readiness, when painstakingly undertaken and executed by a company, goes a long way toward easing that pain for its clients. Failure to do so, however, can result in tenfold the pain downstream for everyone involved.
The people-situation at the outset of my first CEO gig was rocky. We needed to grow and up-skill the team but were in no position to attract top talent. The company was midway through a sizable pivot, cash was dwindling, and our immature SaaS platform needed serious investment. Economic realities had dented our company valuation, making stock options an ineffective recruiting tool; and our dreary, subterranean office-space certainly didn’t help. So, we staffed-up the way so many other start-ups have done in similar situations: we hired eager, inexpensive recent college grads and gave them tons of responsibility. They loved it and responded with energy and enthusiasm. But they also desperately needed training, guidance, and consistent coaching. So, out of necessity, we got good at that.
Specifically, we grew adept in an area that is critical to any growing SaaS business: delegating meaningful work to entry-level employees and providing them with enough scaffolding to aid their near-term success while also supporting their long-term growth. This post addresses one small aspect of this broader challenge that so many growing SaaS businesses face: how to assign projects to less-experienced professionals in a way that works well for individual contributors, for their managers, and for the overall company.
First things first, it really helps for the company to identify one named person to be responsible for assigning work to any given entry-level employee. This may sound obvious, but is certainly not a given in many fluid, early-stage businesses. Among the benefits of this simple step is that it helps the employee avoid the complex, sometimes fraught responsibility of balancing simultaneous commitments to multiple senior people. It also ensures that assignments are given and received via one consistent voice, which avoids a lot of miscommunications.
Beyond the above, though, we’ve found the most important “must-do” is to support every assignment in writing. Even better, do so using a standardized format. A standardized format offers a structured, easy-to-understand written summary that codifies that project for the junior team member. Templates can take any number of forms; and below is an explanation of the template we’ve been using for this purpose at Lock 8 Partners:
Having introduced this tool, I feel obligated to acknowledge that any tool is only as good as a person’s ability to use it. And, while that topic is likely another blog post altogether, we have observed a few simple rules of thumb that help to successfully leverage this tool, including:
In closing, I need to acknowledge that there are no silver bullets to any human challenge; and this template is no panacea. Helping less experienced employees mature into seasoned professionals requires thoughtful on-boarding, purposeful training, consistent coaching, caring mentorship, and so much more. But because these initiatives often require more time and resources than are available in many small-scale businesses, we’re hopeful that this project template can offer a useful tool to help in building and growing your team.
“We all want strong culture in our organizations, communities, and families. We all know that it works. We just don’t know how it works.”
This short video takes a quick look at this great book and adds a few thoughts for those looking to put some of its ideas into action.
Hopefully, this added perspective will make an already awesome book that much more actionable and valuable to leaders of growing organizations.
In dynamic, growing organizations, the relationship between the CEO and CTO is critically important. Unfortunately, this partnership often doesn’t get the attention it deserves. And, in some ways, it is a relationship that is set up with inherent tension. So, what are some things the CEO and CTO should be making time to talk about?
This was a topic I was invited to cover, from a CEO’s perspective, at a recent gathering of CTO’s. Below is a series of short videos that capture and share some of the main points from that session.
Introduction: What is your CEO thinking (and likely not telling you)? — 7 minutes
Part 1: Re-thinking Investment: Building a Dream Home — 3 minutes
Part 2: Bridging the Gap: From Vision to Story Points — 4 minutes
Part 3: Doing vs. Building: The Whole People Thing — 4 minutes
Part 4: Nurturing Purpose: Love Languages and Left Brainers — 3 minutes
Part 5: Surviving Communications: Avoiding Death by Meeting — 5 minutes
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
