Scaling & Managing Your Tech Business
Creating a weekly, monthly and quarterly cadence to grow and operate any tech business successfully
In previous blog posts I’ve written about how you can craft a product vision, how to design and operate products that delight your customers - both the product & engineering side of things. I’ve written about how to design and manage your organization using “golden rules” for structure, hierarchies, and seniority levels. And I’ve written about how to use objectives and key results (OKRs) to set and audit how you’re doing against your top priorities.
An additional ask I’ve heard from readers is for a guidebook on how to create an organization-wide operating cadence, or a “rhythm of the business,” that they can use to manage and optimize their growing tech businesses without becoming too onerous or process-heavy. This post dives into that topic at length, based on what I’ve experienced or seen work (and not work) at growth companies (Zynga, Twilio, DataDog, etc) and larger tech companies (Amazon, VMware) in the past.
If you’re a C-level executive at a rapidly scaling growth company, or a senior leader at a medium- or large-sized company looking to operate more nimbly - this post is for you. If you’re an indie developer, or a new founder at a seed-stage or series-A startup, you’ll find some benefit from implementing one or two of the mechanisms, but applying all or even most of the mechanisms would be overkill. The recommendations in this post will help anyone scale their company, acting as a “blueprint” for how even very large organizations can run effectively, stay focused and deliver business results.
As always, these are the concepts that I’ve seen work, and there’s never a “one size fits all” approach. Depending on the size and stage of your organization, the scale you are operating & your growth rate, you’ll have to modify these mechanisms to fit your needs. Consider my recommendations a starting point.
Here’s what this post will cover:
General Observations about successful companies
Advice on Company Culture
Product/Engineering Reviews
Weekly Mechanisms
Business Reviews
Critical Customer Issues
Operations Reviews
Monthly Audits
OKRs/Goals
Sales Metrics
Marketing Metrics
Org Health
Quarterly Deep Dives
Quarterly Business Reviews
Roadmap Transparency & Product Feature Requests
Deal and Pricing Review
Rolling this out to your organization
I’ll cover annual and long-range planning in the future, as that mechanism is complex enough it deserves its own post, and it stands alone outside this cadence.
With that out of the way, let’s dive in!
1. General Observations
For any company to achieve product/market fit and consequently business success, you need to make your aspirations “real” for customers by building well-functioning, integrated products that delight customers. This has to be reflected in how you design and build the product using a customer-first mindset, how you manage the business - whether it’s the whole company, or an organization operating as if it were a standalone business. It also has to be reflected in how you operate the services and structure the organization .
The most successful companies I’ve seen or been a part of have strong, consistent cultures that work like nesting dolls – where each “inner” layer of the organization operates with a substantially similar culture to the “outer” layer, only at a smaller scale.
To make this work, you need senior leaders to be relentlessly focused on customer outcomes, and to speak and operate with a common voice and expectations across the company, with partner teams internally, and externally with customers.
While you ultimately want each product team to operate independently, and be empowered to make local decisions, companies often prematurely optimize and silo efforts, which results in the offerings and marketing seem fragmented and disconnected to customers. When each product achieves scale in terms of customer adoption and interoperates via hardened APIs (both literally and in the sense well-defined internal prioritization practices), independence is more viable.
I often see this local optimization manifesting as a mismatch of engineering and product management effort when compared to broader customer demand, and what appears as disconnected or zero-sum thinking across GTM, sales and marketing efforts.
Across all types of industries and market segments, customers expect offerings from a single company to feel like a single product offering – with a set of features that they make more or less use of depending on the needs of the individual parts of their company. As one example, DataDog does this particularly well. Even when they acquire other companies, they rebuild the offerings so they have the same look, feel, billing, authentication and so on of the rest of their cloud-monitoring suite. In my opinion, this is a large part of their success.
Marching towards a world where this is true for your products will also simplify and de-conflict the selling and marketing motions, but it requires changing the way you operate as an organization.
2. Advice on Company Culture
You should be relentlessly customer-focused, seeking to anticipate what your customers need by developing well-informed hypotheses - not just through an understanding of the general market, or via sales requests, but by continually reinforced connections between product/engineering and customers. Speed matters disproportionately in business, so operating in a way that lets you validate your hypothesis more quickly, and to put “more wood behind fewer arrows”, is a competitive advantage.
Everyone needs to feel the good kind of paranoia that you won’t be around to see speculative bets come to fruition if you don’t increase momentum in the near-term. To do this you need to drive down ownership into the teams so they feel their success is tied to adoption of products and features, and that they “live and breathe” customer feedback, not just shipping the product, how the team is designed or the shipping process itself.
It’s important not to over-rotate on delivery, of course. If life is brutal for your product & engineering managers because of excessive internal reporting requirements, or it’s really hard to ship software for engineers because of poor pipelines, or there’s too much work to realistically get done, it’ll be a grind every day which doesn’t engender loyalty or get great results. However, I strongly believe people cannot derive a high-level of long-term satisfaction about their work unless they are delivering a high-quality product that: customers appreciate and adopt; and that helps the company hit its business goals.
Don’t reverse cause and effect. Build a culture where career growth & “reasons to celebrate” stem from being attached to a successful business, not the other way around.
To be successful, you need teams not to assume that shipping is where the work ends. Product and engineering need to dive deep into understanding adoption blockers, ease-of-use, pricing issues, etc. Be honest and self-critical where things aren’t working out, even if you believed they would. You should strive to be less philosophically (or religiously) driven about what customers should/might do, and more pragmatic, meeting customers where they are. Product/market fit is the goal through which success and employee satisfaction will come.
In the sections that follow I propose a series of closed-loop mechanisms which are based on bottoms-up thinking, planning and execution, combined with tops-down review, input and auditing. I believe this approach will improve the quality of your decision making, the effectiveness of resource allocation and your success as a business. Creating a “rhythm of the business” by which organizational and business leaders provide updates on a prescribed cadence also reduces the need for ad-hoc/drive-by reports, or for senior leaders to do offline audits via visiting many independent dashboards. Instead, there will now be a short-list of meetings where execs have opportunities to dive deep and ask questions of their org or team leaders.
With curated but cross-functional attendance at these meetings, they also serve as “learning opportunities” for other leaders. When done right these mechanisms will create and reinforce a common company culture, and set expectations for the levels of delivery, ownership and customer obsession you expect from everyone. And owing to the “nesting doll” approach, they allow you to audit that you’re on the right track across a number of axes while being scalable as you add more lines of business.
3. Reviewing Products & Features
I previously covered product definition and related processes at length in this post and the engineering side (design/operations) in its own post - so I’m only going to touch on these briefly here.
Building great products requires you really care about your customers - defining products that will meet their needs; engineering scalable, usable services with a consistent set of APIs; and launching high-quality, operationally excellent products. None of this is likely a revelation to anyone, but you need to enforce standards across the company, and surface the decisions for review before they are made.
I suggest you embrace a culture of creating & reviewing detailed artifacts on your product thinking & engineering designs, and conducting standardized operational readiness reviews before you launch products. The two posts linked in the first paragraph here go into the mechanisms I recommend, and the product post includes a template you can use for your own product/feature definition.
Schedule these reviews on a a frequent and as-needed basis. Your senior leadership could end up reviewing many of these artifacts a week as you become a larger company — so you’ll have to make decisions about what size of new product/feature requires senior leadership review, and which can be reviewed at lower levels. The same thing holds true for engineering design and operational readiness reviews.
One of the keys I’ve seen to empowering teams is that after a product is “green-lit”, it’s up to the team how the work is decomposed into epics, sprints, tasks & milestones. There are other mechanisms further down in this post that ensure the product gets built right, and that the team is on track for delivery, but variability in how each team chooses to operate on a day-to-day implementation basis encourages a feeling of team identity and control. Most companies will end up automatically converging down to a set of daily operating models as it becomes obvious which ones are more successful, and as leaders move up & around inside your company, bringing their methods with them.
Relatedly, you can start writing and reviewing Pricing Documents. Typically in a product definition document, only the proposed dimensions of pricing are laid out, and the more detailed analysis of price point, discounts for committed use, competitive analysis, pro-forma P&L for the service (if applicable) are done later. I recommend you develop a pricing document template with internal finance business partners, so there’s a consistent template across the company. Naming Documents for major new services/features and Competitive analyses could also be created and reviewed via similar ad-hoc review mechanisms.
I also see a place for structured “Customer Advisory Boards” (CAB) in product definition, with those typically conducted on an annual or bi-annual basis, with more frequent ad-hoc touch-points with individual CAB members.
4. Weekly Reviews
The most important thing to get right, in my opinion, is a set of 3 weekly reviews: Weekly Business Reviews, Critical Customer Issues & Operations Reviews. Weekly is the right cadence for this, even when your company is fairly early in its growth trajectory. Daily is of course too often and onerous, but waiting to surface how the business, customers or your services are doing until a month or quarter has passed is too long. I do think there are opportunities to “lift your head up” on a monthly and quarterly basis to look at different aspects of how your business and organizations are doing, and I’ll cover those later in this post.
4a. Weekly Business Reviews
On a weekly basis you must implement mechanisms that allow your senior leaders to have a firm grasp of the state of the business, key trends - and that allow you to reinforce the discipline you expect from your teams in terms of how they operate.
I recommend people institute a weekly business review (WBR) meeting covering all the company (or all of a large sub-division). Something that’s 60-90 minutes in length. This would have relatively wide attendance (could be upwards of 25-50 people) because the goal is knowledge sharing and cultural reinforcement, although it’s not a forum for everyone to have input. You should limit it to certain levels of the product & engineering organization (SVP/VPs + their directs), and senior folks in partner teams (Finance, GTM, HR) with whom you feel comfortable sharing a broad level of financial and product information.
I’ve seen WBRs work best when there’s a rigid structure to the meeting that you follow every week. My suggestion is that a product operations org and/or finance would own pulling a combined deck/PDF together and running the meeting, but teams (product, finance, support) must submit their information by a certain time in advance of the weekly meteing to make this happen. Attendance for senior leaders is mandatory, if the most senior leader (typically VP/GM) isn’t there, the next most senior leader (VP/GM direct) runs the meeting.
Here’s a sample WBR agenda, divided into roughly three parts:
Part 1 (20-30 minutes):
Good News (free-form opportunity to share releases, customer success stories, etc)
Critical customer issues review/discussion (see CCI section below)
Key OKRs review (focused on goals coming up soon, or red/yellow goals)
Calendars of upcoming events (marketing calendar of releases, calendar of first/third-party events) marketing team who own each calendar provide key call-outs/changes
Part 2 (10-15 minutes):
Company-level business metrics for all of the business. Finance would walk everyone through this, calling out any key numbers/deviations from the weekly forecast/plan that factors in seasonality/non-linearity and the reasons/contribution-to-change.
Part 2 (30-45 minutes):
Series of single-page business overviews for each organization/product line in your company that you read for ~5 minutes then discuss for 5-10. The teams need not “present” the data - since it all fits on a single page. If you have more product lines than you can get through in 30-45 minutes, then you create a rotating calendar and only review a subset of the business in-depth each week.
Business overviews are 4 sections split up into quadrants/sections in a single page (often called a 2x2). The single page makes it easy to read/present (for distributed orgs).
A business update that’s metrics-based & focused on not just telling the news but answering “so what”
Top level OKR status (not a goals deep dive, just the top 2-3)
Key risks/issues/challenges (e.g. competitive losses, feature delays, quality issues, marketing awareness, etc)
Upcoming releases/roadmap
For the WBR, each business/org produces a 2x2 every week and the VP/GM is prepared to speak to it, along w/maybe heads of product/eng if needed. Each VP/GM should have their own WBR mechanism prior to this company-wide WBR, where they are reviewing this inside their org. Some very large orgs might replicate this process, and have sub-parts of their org produce team-level 2x2s that they only review amongst themselves.
I found PowerPoint a poor substitute for Microsoft Word or Google Docs (or even Workboard’s “Business Review” feature) for this purpose - PowerPoint makes it hard to get the information density needed, and people spend too much time on “SmartArt” and formatting. I put a sample template in the appendix of this post.
During each 2x2 review it’s expected to be a detailed deep dive into each business’ current state. It’s not an annual plan, quarterly business review narrative or super deep philosophical discussion, but gives executives the chance to see how the business is doing at a fairly deep level, on a frequent basis, because of the information density.
To be specific, the expectation during 2x2 is that a small group of people like your C-level and SVPs would be asking questions of the business leaders and they’d be expected to answer. This helps give you an idea who’s on top of their business (and who isn’t) & whether they’re “sweating the issues” (i.e. if they have a set of risks/issues but no plan to mitigate them, or no urgency, that’s not good). Questions from senior leadership also serve as an example to the other business leaders – who should be listening for what they should put in their 2x2 and how you expect them to run their businesses.
Follow-ups (a request for a product document, a deep dive into customer issues, etc) may arise out of WBR. A product operations team would track these. Those are not conducted inside the WBR itself. This may seem “heavy” but it replaces an enormous amount of checking other dashboards, ad-hoc/drive-by status requests, etc – both for the senior leaders and the product line/business owners underneath them. A well designed WBR is a scaling mechanism that reduces overhead.
4b. Critical Customer Issues
The day prior to the WBR your support organization would run a “critical customer issues” (CCI) meeting. This is not a review of all the issues a given product, team or customer is facing, but a curated list of serious issues facing your top customers (or top prospects) where the customer temperature you would now define as “yellow” (at risk of escalation/loss of business) or “red” (being escalated, significant chance of loss of business). It is also not the place to discuss product feature requests (PFRs) from sales. I discuss customer feedback mechanisms at length in my previous post about product/feature definition.
You would create a template (Word/Google Docs or some structured data from a web-based form system) for CCIs that the Support org owns since they own managing the meetings, follow-up & customer interactions - but the product/engineering teams and sales help fill out this document. Sections would include:
Customer info
Supporting/sponsoring executives (inside your company)
A crisp issue summary
A “get to green” plan with milestones/due dates & status updates.
It’s possible you’d have as few as zero to one CCIs per week, or as many as five or more. If you have the same issue facing multiple customers (e.g. a major outage that impacted a large swath of customers) you can consolidate all of those into a single CCI. Teams are expected to work the CCI as frequently as needed (daily, etc) to drive to resolution. The weekly meeting is simply when the right people (support, sales & product for each issue) get together to discuss the update they plan to present at the WBR. Ideally people who’ve been through numerous CCIs are consistent attendees at this meeting to help newer leaders.
4c. Cross-Org Operations Meeting
To drive operational excellence, security, reliability, scale into the product and into how people deliver, you need a vehicle to audit those dimensions and for everyone to see that you’re driving this across every product/service on an ongoing basis, not just as part of engineering design or operational readiness reviews before you launch a new product.
One thing I’ve seen work here is cross-org operations (ops) meetings. Here you’d have a wider attendance from engineering VPs down to the SDMs (first-level line managers). Attendance for this is mostly engineering & engineering leaders, with product invited but optional. You could suggest mid-level and even junior engineers attend periodically to see what the company cares about in terms of service delivery, quality, etc.
A sample agenda would be:
Good News where people celebrate engineering, or quality wins
Company-wide initiative updates - such as if you’re all adopting some new shared tech and there’s a status on who is/not adopting; or there’s a requirement every team does something specific for a new external compliance regulation
Periodic dashboard reviews for services (even those that haven’t faced recent outages). I recommend rotating through your services, using a schedule/calendar.
Outage/Post-mortem reviews from previous week’s outages, presented by the team who experienced & recovered from the outage.
This is a learning meeting but there are aspects of “sermon” here as well from the leadership. It is not a business/product/project update, with the exception of the initiatives section. Ideally your most senior engineering VPs and the Principal Engineers (PEs) would be asking questions of each team that presents. Again much like WBR, this may feel “heavy” - but it’s a single meeting replacing most other ad-hoc requests for this same information; helps reinforce org-wide emails about the company-wide initiatives & provides a forum to discuss them; and should result in team leaders taking away lessons from other teams back to their own team.
5. Monthly business audits
On a monthly basis you can audit progress against OKRs/goals, along with diving into observations & progress from sales and marketing. Auditing OKRs more frequently is wasted overhead as people don’t move the needle towards goals that quickly. Similarly sales and marketing will have their own internal operational reviews on a weekly basis, and your goal as a leadership team is simply to audit those, not micro-manage the teams, which makes monthly a more appropriate cadence. If things are going perfectly well and the org/business isn’t changing rapidly, it’s possible to move these to a quarterly cadence, but I recommend starting with monthly. If you do this right, it’s 4 hours of total meetings for the monthly audits, plus the prep time for the teams, but they can get that down to a science.
5a. OKR/Goals Review
Assuming you’ve created a good annual or long-range plan/strategy, you can create OKRs (objectives and key results) or “SMART” goals that align with that plan. I extensively covered this in my previous post about using OKRs to manage your business - including a whole guide on how to write good OKRs.
Once you have your OKRs, and you’re tracking them in a system (Workboard, Asana, etc) – that then enables a single monthly review across the whole company or organization. As a sample agenda I’d recommend you sort the reporting/dashboard to
Start with discussing at any OKRs that are red/yellow (in trouble/at risk)
Then discussing OKRs that are coming up/due soon
Then overall attainment measures (for each major org what % of goals are red/yellow/green).
Back to the “nesting doll” analogy - you should be looking at “company-level OKRs” here, not the “team level” KRs. Those may roll up, contributing as a part of a company-level KR, or just be things that team thinks are important, but you’d scale by not reviewing them directly in this company-wide OKR goal/review meeting.
Org and team leaders should replicate this process at their level - that is, they should be looking at all their own OKRs monthly as well and having the same kind of discussion inside their orgs about goal attainment. They will do this in preparation for the wider goal review, but also as a form of cultural reinforcement that OKRs matter and their leaders are looking at them.
A product operations org would help pull together the views and dashboards, but people who own the goals are responsible for speaking to them, and updating the KRs in the system. KR owners are expected to speak to why KRs are red/yellow, and if they’re “truly” green for any impending goals. A sign your org is taking OKRs seriously, and that your leaders are on top of their business, is that every senior leader is prepared to discuss any KR you ask them about at this review meeting, versus requiring some much lower-level person to weigh in.
5b. Sales & Partner Metrics Review
Here you would ask your sales leadership to first produce a “top observations by product” list that you review first. Each sales group (a specific geography, or industry vertical - how ever you have aligned the sales org) produces a single-page 2x2 style update (like the WBR) for their area of sales. The sales operations team would be responsible for pulling this together from the parts of the sales, SE and service organizations.The goal is you have sales, product and executive leadership in a meeting to have a crisp and direct observation about wins/losses, what’s working/not in the market, etc. This is not a detailed roadmap or PFR review (see quarterly deep dive section), although sales teams may bring up gaps they believe are hurting sales.
The sections of the 2x2 would include:
An overview of the “business” (sales team/territory) with a forecast, key activities, and key upcoming deals
Consolidated table with attainment against any goals (including green/yellow/red and actual $ amounts, # of accounts, etc)
A sales focused "risks/issues/challenges” section which can be about more than product - could be about sales training/confidence, macro-economic events, hiring challenges, etc.
Top highlights & lowlights (wins & losses).
Attendees would include senior product & executive leadership, along with sales leaders (and their senior staff who produce and review the 2x2s).
You could do this weekly (like the WBR) but sales forecasts don’t change materially week-to-week, and there are too many sections to try and shoe-horn this into the WBR, which is designed to be product/service/business focused.
This also doesn’t replace or eliminate any 1:1 customer outreach on ad-hoc basis for product/engineering teams. Mechanisms like executive sponsorship, the CAB, etc fit in/around mechanisms like this but don’t replace looking across all of sales on a monthly basis.
5c. Marketing Metrics Review
Very similar to sales, you have each part (product line, industry segment, etc) of marketing produce a 2x2 along with any supplemental metrics/appendices about campaigns and content. 2x2 contents would include
An overview section (metrics, recent interesting results from marketing activities, etc)
Marketing focused risks/issues/challenges
Top OKR status
Upcoming campaigns/references/etc (instead of a product “roadmap”)
You can use this meeting to cover product marketing, brand marketing and analyst relations efforts (with each team producing their own 2x2. It is expected that marketing would be aligned with the product orgs they support on these efforts - in that the product orgs wouldn’t be “surprised” by what they read about here, but instead review it beforehand and have plans to address any product-specific issues.
Attendance is similar to the monthly sales metrics review - except that marketing/AR are the creators and presenters of the 2x2s instead of sales.
5d. Managing Org Health
I’d strongly recommend org health review meetings be separated from these other operational mechanisms (other than knowing at a high-level how a team is doing against hiring goals, or if attrition is hurting delivery). Org health is a complex, deep topic, and it can either be given short-shrift if stuffed into a business/ops review, or threaten to overwhelm discussions that need to happen around product, engineering & GTM.
I recommend a comprehensive monthly org health review where you review a set of metrics by org and across the org, that relate to your goals around: Spans & Layers, Diversity & inclusion efforts, Hiring Velocity, Attrition, Location Strategy, and General Org Sentiment (ideally measured by some sort of structured surveys).
This would be attended only by the most senior leaders (SVPs, VPs, PEs) in the org and the HR business partners (HRBPs) that support those orgs. As needed you could use these meetings for “special topics” section in these meetings where you dive deeper into a relevant topic like cleaning up job reqs, composition/cost by org (location spread), recruiting accepts/declines/pipeline, etc. When there are top-down driven exercises such as “what would you do with 10% less headcount” this is where you’d have that discussion started/kicked-off.
Org health needs to be more appropriately compartmentalized and discussed with a group of senior-level people that are able to have the right level of transparency, trust and discretion - whether discussing diversity, attrition, performance management and even your “return to office” program. Calibration across those topics does not exist in wide forums like the proposed WBR, Ops review or OKR reviews. Nor do I recommend ad-hoc discussions on Slack, or via email. These are ineffective in moving any organization (let alone the whole companies) to where it needs to be in terms of org health - or making decisions about headcount re-allocations.
Similar to operational & product mechanisms, VPs should mirror this org health review mechanism with their management team and HRBPs, but in those meetings they would only be discussing trends and observations about their own organizations, ideally as preparation for coming into the company-wide health meeting.
It’s also important you not over-rotate on any single aspect of org-health. Loud voices can dominate these conversations, and while you need to listen to everyone, you also need backbone to avoid people monopolizing or co-opting your focus to serve their own agenda, at the expense of the set of factors that you know create a thriving org. Those are covered at length in my post about Golden Rules for Org Design.
6. Quarterly Deep Dives
On a quarterly basis your teams would provide narrative updates into the state of each business that are more comprehensive than WBRs and OKR reviews, and that capture thematic progress and challenges. As well I recommend quarterly meetings that look out ahead comparing the roadmap and review product/feature requests from sales in a structured manager, and potentially a “deals” review as well.
6a. Quarterly Business Reviews
A quarterly business review (QBR) is a deep, thoughtful narrative (Word/Google doc - not PowerPoint) that covers the actual health of each business and organization. Because these require depth of thought and require that you assemble information from across a VP/GM’s organization, doing these more than once/quarter is too much overhead. As well, because you want to have enough time for the conversation, you’re reviewing each business/division’s QBR one at a time, which then requires multiple meetings, so you don’t have the time to do these more than once/quarter.
I suggest you provide a standardized document template with required sections, but allow each leader to find their own voice in the narrative itself. Information should be qualitative and quantitative, but not merely anecdotal. Recommended sections include:
Overview of business Health (extended version of WBR data, working with Finance)
High level org stats (hiring against headcount targets, attrition rates)
Engineering update (including compliance, security, quality efforts, ops stats, etc)
Major product/feature updates (not a full lengthy roadmap)
Relevant customer anecdotes, etc
Conclusion/Takeaways
An approach I’ve seen to scale this effort, is where VPs/GMs assign each section to the appropriate person in their org (so the engineering head writes the ops/eng section, the Sr Director of Product the product/feature update, and so on). The VP/GM then pulls the final QBR document together in a single narrative voice, as well as reviewing for whether it tells an appropriate story given where the business is.
This should be a clinical examination of the business, and is not a place for hyperbole, excessive optimism or pessimism. Narratives should be supported by appendices with charts/graphs/etc, but should not be dozens of pages. At Amazon 6 pages was the maximum limit for the body of the document, but if you could tell a story in less, that was great. When my org got large enough that I was having individual product-lines present QBRs to me, I gave them a maximum length of 2-3 pages, considering I had to roll up the entire thing to my boss in 6 pages.
The precise number of pages matters less than the notion you’re not looking for a book-length essay. So pick a number that’s reasonable (5-8?) and where you can read the QBR in 15-30 minutes. Your goal is to get a deep-dive into the business in this silent reading time, and then you can ask questions that either directly relate to what you read, or that you believe are the most important issues facing the business and you don’t see how they’re being addressed.
Since you want to be able to have high-fidelity, transparent conversation, the audience should be more narrow than the WBR or monthly metrics reviews. We’d have the C-suite/SVPs, the VP for the presenting business and their leadership team, and key partners from sales/marketing/HR/finance only. It’s sometimes beneficial to have peer team VPs listen in, or occasionally answer questions, but the primary audience for this review is the executive leadership at the company level.
6b. Roadmap Transparency & Product Feature Requests
Another mechanism I’ve seen work to add structure is a bidirectional roadmap and product feature request (PFR) review on a quarterly basis. This can be a 2 hour meeting, along with recorded enablement for sales.
Here the product teams are presenting the next 1-2 quarter’s roadmap (and some visibility further out) to the sales teams, as if they were also presenting them to customers under NDA, typically with a PowerPoint style roadmap doc with a little context added, but not a narrative (just voiceover). This helps the sales leadership align with the product leadership on what’s officially coming and can be “pre-sold”, and how the product teams are packaging it/describing it to customers. I’d argue against sharing full-year precise roadmaps with sales or customers. If further visibility is necessary, the practice I’d recommend is a rolling roadmap where you bucket features into “this quarter” (where you should be highly confident they will launch), “next quarter” and “things we’re considering for 2nd half of the year”. In this way both sales and customers have visibility but it’s made clear things further out aren’t hard commitments, but more soft targets, where there’s an opportunity to provide input to shape roadmaps.
I’ve actually seen using this same presentation at Sales Kick-Off (SKO) meetings and with strategic customers (one-on-one or via the CAB mechanism) as a helpful way for product teams to get structured feedback directly, without committing to specific functionality launch dates.
In the second half of the meeting the sales, marketing, customer insights team is presenting a structured/curated view of the PFRs along with some context (opportunity size, number of customers, etc) to the product teams. There’s more regular flow of information between customers and product teams from ad-hoc, direct interactions, but the sales team will always meet with an order of magnitude more customers than the product team and so can start to quantify top PFRs in a way that helps product teams determine if they’re on the right track.
The structure of the PFR review is fairly straightforward. It should include:
A stack ranked list of PFRs with the quantity of customers requesting that feature
Some notion of the revenue behind each PFR & some context behind the request;
And whether or not this is mapped to a roadmapped deliverable already (and in which quarter).
Sales and product teams should have a discussion to understand why there might be “top PFRs” that aren’t yet on the roadmap, and what the plan is for those, and if there are alternatives to what customers are asking. Product teams should also use the PFRs during annual planning as evidence that they’re listening to customers and that their planned initiatives address the top PFRs.
A product operations org and sales operations would help facilitate. Product leadership would attend along with sales/SE leadership.
6c. Quarterly Deal/Pricing Review
As you sell more bundled deals across the company’s product lines, you should develop the discipline of reviewing the deals for the previous quarter. Working with finance and sales operations an analysis would be prepared on:
What are the deal trends in: deal size, discount levels, product mix, review/approval velocity
Discounting - How many deals used standard/pre-approved discounts & how many required custom discounts/approvals
For deals using standard discounts, is there a recommendation to consider in making this part of the product offering (such as via a committed-use discount that’s publicly available)?
For deals that required custom discounts/approvals, a deep dive on each to determine if there are any commonalities that would lend themselves to creating a pre-approved offering (even where it still requires some approval) to standardize and make deals more efficient.
Collectively, this is an audit on whether your pricing/packaging strategy is working in the market.
7. Phased Rollout Plan
Rolling these mechanisms out will require both a phased approach and training as there’s a cultural shift you’ll want to explain to people in terms of what they’re expected to produce and questions you’d expect them to answer.
To do this you’d create the templates for the first set of mechanisms, settle on the attendees, walk teams individually through a “mock” mechanism. For example if you plan to roll out the WBR first, have your core teams produce their content, have a product-line or two produce a WBR 1-pager, and then ask each group questions about their content individually, but not in a wider group, to give them feedback/coaching. Then you’d schedule the wider group meetings (in this case, the company-wide WBR). Along with this you’d create an “overall rhythm of the business” calendar with all the weekly/monthly/quarterly meetings, who attends, who presents – that shows how these meetings work together and what the purpose is.
As you roll these out, I would also expect that your VPs create their own org-level versions of some of the Company-wide mechanisms (WBR, Goal/OKR review) to reinforce a common culture and because they need to do pre-reviews of anything being reviewed at executive management levels.
The product operations org can help with in terms of creating templates, and writing guidelines (wikis, Google docs, etc) but teams would be expected to run these meetings themselves (large teams may have their own product ops orgs). While I expect variability in how each organization operates, you wouldn’t want each org to create an entirely different set of operating rules for how they manage the business, as it has to nest and interlock into these top level company mechanisms.
In terms of making sure the company can digest this while continuing to make progress on their deliverables, I definitely don’t think you should start with the heaviest weight mechanism - annual planning. This is also part of why I am saving this for its own, future post.
For the purposes of this plan, I will assume you already established the discipline of reviewing your product & engineering documents on an as-needed basis. If not, start with that.
Based on delivering value to the organization and being operationally achievable, I recommend starting with the set of 3 weekly review meetings: WBR, CCI, Product Reviews. Then a couple months later, the Monthly Mechanisms: OKR Reviews, Org Health Review, Sales Metrics, Marketing Metrics; Then once that’s working, do your first Quarterly deep-dive cycle (QBRs, Product Roadmap/PFR meeting, Deals Review).
If you begin to feel that some orgs are wildly off track in terms of either approach or execution while you’re rolling this out, you can specifically request a “state of the business” narrative at any time, which the teams would then have to produce outside of the usual operating cadence.
When I rejoined Amazon, in AWS, back in 2014, I produced a WBR 2x2 for my business (EC2 Spot, at the time). At the AWS WBR, Andy Jassy reviewed my 2x2, asked some questions, and then requested I produce “State of the Spot Business” doc within a couple of weeks. It was a tough exercise considering I’d only been running the business for 6 weeks, but it was super valuable, and good we didn’t wait until the next annual review. Out of that deeper review, we got buy-in to grow the EC2 Spot organization and commit to some speculative “big bets” that propelled the business forward significantly.
By following this phased rollout for your operating cadence, you come around to your next annual planning time again you’ll have so much more structured input to put to use.
Takeaways
The opportunity to bring value to customers, who have real problems your technology products can solve, is as great as ever. Even in the cloud computing space, somewhere between 75% and 90% of technology spend is still on premises.
You need obsessive focus on what customers are telling you they need, and to whittle down your efforts to the set of deliverables that will deliver value to the broadest set of customers now. And I see a strong need for companies to reduce the distractions or diffuse efforts that threaten to throw us off course.
Operating as a unified organization with common mechanisms for product design, engineering/operational excellence, and for auditing the business will reduce overhead, and noise and will continually reinforce the culture of performance you need.
And while not specifically focused this post on this, I have observed that people are happier and feel more included when they know the: 1) “why” of what they’re doing; 2) when everyone is visibly held to a fair, high standard; and 3) where they are working on a product that’s succeeding in the market.
Lastly, a focus on mechanisms also reduces single points of failure, where you are relying on the skills or execution of individual leaders who maintain tribal product or engineering knowledge in their head about why and how decisions were made. These mechanisms make the organization more durable and resilient to employee turnover or organizational changes (whether planned or reactive).
Now go out there and build!
Appendix 1 - Other Mechanisms
There are other mechanisms - for example, staff and leadership meetings where each manager/director has their directs in every week or two to go over topical agenda items, org health/management programs, etc. Or how Engineering/Product Managers run their sprints and retrospectives. I don’t believe you have to be prescriptive about the other meetings or ways that people run their individual orgs (esp at the Director level and below). Or individual weekly interlock meetings between the field and each part of the product org with whom they are working. Similarly, weekly or monthly emails to the team from team leaders help keep the average employee informed of what’s going on, as most are not invited to all the meetings I’ve described in this document.
Other mechanisms I’ve seen work are off-sites covering special topics prior or in addition to annual planning cycles to cover cross-company priorities or topics that don’t fit neatly into any single business. You can solicit topics and have people present their narratives on these proposed cross-cutting initiatives at an off-site to the company leadership team. An example might be the “common core” tooling for packaging, release & distribution. Or another example might be developing a “personas” document that product managers could use for their product documents. This could be presented during an off-site or as prep-work for annual planning, and then factored into your plans as you carve out resources to work on this.
I also haven’t addressed here Company wide HR meetings, such as hiring, talent reviews, mandatory trainings about comp/bonus, etc. For example, if you want to create a common hiring standard (such as assigning competencies for the different interviewers, doing formal debriefs, etc), that would require its own implementation and review process.
Appendix 2 - WBR Template
This is the text-based version of the single-page landscape-orientation table I included earlier. I find the landscape-orientation helpful so you can include it in a combined PDF or deck that you use for the WBR (combines with the CCI overview, Finance/Business overview, and other team’s WBRs) nicely that way
Business Overview - <Product/Service>
Business Owner: <Owner Name>
Document Author: <Document Author Name>
Reviewed By: <Reviewer(s)>
Last Updated: <Date>
<Template notes: Fill in items in <brackets>. Delete instructional guidance in italics when filling out text. Total length of Business Overview cannot exceed 1 page>
Business update
Use full sentences. You may use bullets if needed for formatting, but must use sentences (as there will not be a presentation/voice over, this will be read by the execs).
Start with a crisp update on the metrics that matter to your business, including bookings/revenue/ACV/ARR, renewal rate, usage, customer totals & new logos, customer adoption rates, quality metrics, etc. Indicate both where you are, and whether you are at/ahead/behind plan (numerically) and how much you’ve grown or shrunk YoY (year over year) and MoM (month over month). Use both input and output metrics.
Then list interesting customer adoption or recent releases or marketing updates in additional sentences.
Focus on not just “reporting the news” but answering the “so what” (why does this matter, why is it interesting/compelling information). This should be “standalone” for the reader and not require voice-over to understand.
Note: For metrics you should have to run the business, but currently don’t, please indicate what your plan is to get them, in the risks/challenges section
Key risks/issues/challenges
Use bullet format with full-sentences. Can be competitive losses, delays in getting key features out the door due to attrition or execution issues, quality issues, falling behind revenue/usage, marketing awareness, challenges working with the sales org, etc. This is your opportunity to highlight to executives what the risks are to delivery, growth, consumption, customer sentiment, etc. Sample format is below.
[Risk] Risk Name - Description. Mitigation/Plan
[Issue] Issue Name - Description. Mitigation/Plan
[Challenge] Challenge Name - Description. Mitigation/Plan
Upcoming Releases/Roadmap
List top priority/needle moving upcoming features here. Do not erase previously committed dates, use strike-through instead. Sample format below.
Roadmap Item 1 -
Original Date, Recent Old Date, New DateRoadmap Item 2 - Date
Roadmap Item 3 - Date
Top OKRs
List status on Top 3 KRs. Note that this isn’t a KR deep dive, which occurs during the monthly OKR review. Just a reminder what the top OKRs are that you are prioritizing for your domain. Sample format below.
OKR 1 - Red/Yellow/Green
OKR 2 - Red/Yellow/Green
OKR 3 - Red/Yellow/Green