The ideal customer profile dartboard, and an enterprise readiness scorecard nobody wrote from the top: Greg Strickland of Productboard

An ideal customer profile is usually a single description of the customer you want. Greg Strickland's version has three rings, and the middle one is the interesting part: companies you know are a stretch, that you will close anyway, because you intend to build the product alongside them.

Strickland is COO of Productboard, the product management system used by Microsoft, Zendesk and Avast, and approaching $100 million in annual recurring revenue. Before that he was COO at Periscope Data, and before that International General Manager and VP of Global Operations at Box.

Michael is a former customer, which shapes an unusually specific conversation.

Saying yes, and how to decide

Strickland has said his success came from saying yes to opportunities where he felt out of his depth. Michael's question is how you decide which ones.

His filter is two questions. What does the business need in order to move forward? And is anyone else able or willing to do it, with enough commitment to see it through?

Usually, he says, the answer to the second is that nobody is.

The underlying orientation is what makes it work. If you prioritize your career over learning and moving the business forward, you say no more often. He has never had that mentality, which is also why he likes startups: what you can learn in a year is three to five times what a single individual contributor role at a large organization would give you, because there is always more work than people and never enough resources.

Michael's summary is right. Experience over title. Get the experience and the title follows.

Strickland's path to COO was exactly that: saying yes to cross-functional projects, standing up new departments from zero to one, interviewing and hiring people better than him at their function, and, in his words, putting his ego in check to make sure they succeeded.

When he says no

Two situations.

The first is when someone else should do it, particularly an up-and-comer he has watched operate and wants to stretch. He notes this happens more as you get later in your career, when part of the job becomes creating those opportunities for other people.

The second is disagreement about strategy. With first-time founders, the quality of decisions based on experience varies enormously, so sometimes his no is a considered judgment that this is the wrong call. His framing of what that requires is the useful part: push back and have the dialogue before the organization knee-jerks into doing whatever the CEO wants.

Two-way doors and finding mentors

Michael raises the pitfall of early-stage companies, which is that there is often nobody to learn the job from. Trial by fire.

Strickland agrees, and then argues the fire has value. Sometimes you need to walk over the cliff. The critical distinction is one-way doors and two-way doors, and his estimate is that 90% of organizational decisions are two-way: you make a mistake, you walk back. What matters is making sure the project you fumble is not company-ending.

He also thinks the situation has genuinely improved over the last decade. People will respond to a LinkedIn message and share expertise. There is a large volume of writing from experienced investors and operators that lets you do the academic part rather than charging blindly up the hill.

Michael's illustration is a good one. He read Matt Blumberg's blog for twenty years, Blumberg being the founder and CEO of Return Path and the author of Startup CXO, then finally reached out a couple of months before the recording and found him generous with his time.

Asked why the sharing increased, Strickland does not claim a grand theory. He came out of college into the dot-com bust, lived through 2008, and has been through layoffs, downsizing, IPOs and acquisitions. More people who cut their teeth over the last ten to fifteen years are now sharing what they learned. The canonical books have always existed, The Hard Thing About Hard Things, Frank Slootman's Amp It Up, Radical Candor. What changed is a broader willingness toward perpetual learning.

His view on why it matters: there is nothing better than a former operator sharing their war stories and confirming that you are not the first person going through this.

Why he keeps working with first-time founders

Michael calls it painful. Strickland agrees and calls himself a glutton for punishment, then gives an honest answer.

He has always been entrepreneurial and wanted to start a company. He just does not think he is that creative. He has had maybe three good ideas, each of which someone else eventually turned into a good business. He never had the idea that kept him awake at night.

So the way he lives that ambition is by partnering with people who do have the vision, and helping them realize it.

He is candid that it costs. Physically, emotionally, mentally. He describes himself as binary, all in or all out, and all in means taking a lot on his own shoulders, because he knows how hard and how lonely the CEO job is. His observation about the consequence is worth noting: doing that earns you more responsibility, because people can tell whether you actually care.

His preference among founder types is instructive for anyone considering a COO role. He has never owned product or engineering, and gravitates toward product and technical founders precisely because of that. His strength is scaling the rest: finding go-to-market leaders, building finance and people operations, and operationalizing the cadence of the business. Those are usually not a technical founder's core competencies, so the fit is natural rather than negotiated.

Why one company wins and its twin fails

There is no silver bullet, he says, just a combination of lead bullets. But he does not discount founder conviction and vision.

The question is whether they built something because it seemed interesting, or whether they can see where it is going and bring people with them. Because if the vision is well defined and constantly restated, the decisions behind it become much easier and start to compound.

His example is Productboard's own. The vision is to be something like the Salesforce for engineering, product and design. It begins as workflow management, and through the workflow you capture a large amount of data, and that data becomes valuable in itself, the way Salesforce reporting is.

Without that, you start from feature functionality solving a basic problem, and it becomes very easy to get sidetracked, lose focus and chase whatever is shiny. In a startup with limited resources, everyone needs to pull in the same direction.

And then luck, which he refuses to pretend away. His Box example: Aaron Levie had the vision and was relentless about selling it, and they built resources behind it. Then the iPad launched partway through, and Levie went through the organization declaring they would be the first business application on it. Market dynamics move for you or against you, and what matters is how fast the founder reacts and how nimble the organization is at absorbing it.

AI is a product problem now

Strickland splits it in two.

Operationally it is straightforwardly exciting, an efficiency question across every function.

On the product side, his framing is the sharp one: AI is now a product problem rather than an engineering problem. Somebody has to decide how and where to insert it into the existing flow, or reimagine existing functionality with AI in front of it or beside it. He cites a survey suggesting 70 to 80% of companies were working out their AI product strategy at the time.

Where they use it internally: content, product marketing, summaries, note building, design elements, and sales outreach where research on a prospect can drive bespoke sequences.

Where it applies to the product itself is more interesting. Productboard's insights module integrates across many systems and pulls in customer research. Automatically surfacing themes by segment, your biggest customers, your smallest, a region, an industry, saves product teams a great deal of manual reading.

On customer data, he is refreshingly honest that nobody has solved it. You cannot do anything unless customers know what you are doing and proactively opt in, absorbing the risk themselves because they want the capability. Or you start with things that do not touch customer data. Unless you are training your own closed models, that is the state of play, and the requirement is explicit communication rather than a clause nobody reads.

Buffering the team from whiplash

Asked how you protect people from constant reprioritization, Strickland gives four answers.

Set expectations up front, and source for it in interviews. Everyone claims to be dynamic and fast moving, but you should be honest about what that costs.

Give enough stability that things actually ship and you learn something from them.

Speed up the reporting and goal-setting cadence, and build a culture where changing goals and moving resources is understood rather than alarming.

And ring-fence the long-term initiatives you fundamentally believe must be true. Protect those teams and give them a longer charter. Everything else runs on sprints and experiments, where being pulled onto a different bet is the normal condition.

His argument for why this is worth the discomfort: a startup can reorient goals in a month, possibly a week, and deprioritize and reprioritize freely. That takes weeks, months or years in a large organization. Speed is the advantage, and preserving it has a cost you should pay deliberately.

Product operations is the next ops function

Strickland traces the pattern. CRM systems produced sales operations. Marketo, HubSpot and Eloqua produced marketing operations. Gainsight and its peers produced customer success operations.

The same thing is now happening with product. People who own the system of record, drive the insights through it, and effectively run the process of product management.

And behind it sits a question every finance leader is now asking. We hired a large number of engineers and product people. What is the return?

His observation about why this is new is fair. Sales has quotas and ratios. Marketing has pipeline and return calculators. Customer success has portfolio management and net revenue retention. Engineering, product and design have never been indexed that way.

He thinks the change is good, because you want to understand inputs, outputs and throughput. And he expects finance and operations teams to play a growing role in assessing how effective the product organization is.

Why the Salesforce comparison is the right one

Michael raises the obvious objection: this sounds like surveillance, and reminds him of how salespeople first received Salesforce.

Strickland's answer is that an individual account executive was never going to adopt Salesforce voluntarily. They could organize their own opportunities in a spreadsheet. It is an organizational push, and the reason is predictability, accountability, and better decisions.

If you do not know your pipeline coverage or your forecast, you cannot decide where to invest. And if you do not know the effectiveness of your engineering, product and design organization, you cannot know whether you will hit milestones or respond to customer needs, or whether what is being built connects to company objectives.

His framing: you will have leaky funnels in engineering, product and design exactly as you do in sales and marketing. This is not about control. It is about finding them.

How he gives feedback without giving direction

Strickland hires self-starters who want calibration rather than instruction, and says he has never been a micromanager. Michael asks how the calibration actually works.

The answer is entirely questions.

Have they thought about this? What about this option? How are they thinking about this eventuality? How will they know if it succeeded? What are they judging success on?

His reasoning is the part that matters. There tend to be a lot of outputs, assets produced and events run, and comparatively little clarity about outcomes. So the question is which numbers, moving how much, over what period.

And the compounding effect: the more you do this with someone, the less you have to, because they internalize it. Eventually they arrive with an experiment that already has numbers, grounded in baselines and past performance, and your role becomes a sounding board on tactics.

Moving upmarket

Enterprise is always hard for a startup, and Strickland names the specific tension. You have startup nimbleness, which is valuable at certain stages, and then you have to appear stable.

The other half is finding where the product genuinely creates value at that size, and there is usually a slice that adopts first.

Productboard started as a startup selling to other startups, then sold to larger software companies. The slice they found was different: companies where building software is not the core competency. Retail, healthcare, logistics, financial services.

Retailers now have to build e-commerce sites, digital loyalty programs and mobile applications. Healthcare has to build digital patient experiences and scheduling systems. Some of it accelerated through COVID and some is a longer trend, but all of it means companies that are not software businesses now have to do product management.

Which changes what Productboard is selling. Not just a system, but the best practices and learnings from strong software companies about how they do product. The change management value, as he puts it, is large.

His summary of operating in a hard market is one to keep: find what is working, go hard at it, operationalize everything else, and get so good at the thing that works that you are ready when the market returns.

The enterprise readiness scorecard

This is the most portable idea in the episode.

Three-plus years into moving upmarket, Productboard built an enterprise readiness scorecard. The crucial choice was decentralizing it.

Every department evaluated itself. They defined their own categories and scored themselves, on the reasonable premise that people have worked at different sized companies and know how their own function operates. Then the company used that scorecard over the following two years to make progressive improvements.

Strickland is emphatic about why it was not top-down. It was not him telling engineering to do three things. It was engineering and product saying what re-architecture was needed for scalability. That produced ownership at the department and individual level.

His broader point: startups are full of people with relevant experience from companies that sold to enterprise and companies that did not. Crowdsource it, then have the management team make sure the right pieces get attention in the right order.

And the warning. Moving upmarket is a company-level initiative and a total team sport. Some companies never make the transition, or actively fight it, because of their DNA and their founders. So the first thing to establish is whether the willingness and belief exist. Without them you are pushing a boulder uphill.

Pod zero

The name is made up, and the model is straightforward.

If you have traditionally served small and mid-sized businesses and have just closed your first few enterprise customers, those customers are different. Different delivery model, different timescale, different statement of work. Do what you have always done and you will be surprised at renewal.

So Productboard deliberately assembled a dedicated group around those accounts: a services person, a strategic customer success manager, a product sponsor, and the account executive, all working collectively to make that customer successful so they expand and become a champion.

And when you are moving upmarket, champions are the asset. They feed the marketing flywheel and they tap their own networks. Making them successful, while knowing you are still a startup with an immature product, requires deliberate investment.

The dartboard

The ideal customer profile model, in his words taken from other companies' best practices, is a dartboard.

The bullseye is where they have come from. Companies they know they sell to well, whose needs they understand and can already meet. Those customers will still ask for new integrations, but it fits.

The middle ring is the stretch. They may not know holistically what those companies want, but they are willing to close them and co-create the product with them, in order to eventually win more companies that look like them.

The outer ring is where they will not sell. Those customers would be unhappy and would churn, and his rhetorical question is the right one: why would you put yourself in that business?

The value is the focus it creates, and the ease with which the organization can say no to a sale that will leave in six months.

Consistency of signal

The related discipline is about feature requests, and the failure mode Strickland describes is one everyone has heard about.

A company sells a very large enterprise deal that becomes the overwhelming majority of its revenue, builds specifically for that customer, the customer churns, and the company does not survive. What causes it is building things for one customer that do not apply to a broader industry or use case.

So the filter is consistency of signal. What Productboard hears repeatedly from enterprise customers is not exotic: granular permissioning, performance at scale, better reporting. The more at-bats, the clearer it gets. Find the overlap in the Venn diagram, which probably resolves 80% of the problem, and resist building everything each enterprise prospect asks for.

He adds a caveat worth respecting. In business intelligence, people are extremely particular about chart types and interface behavior, so a long and legitimate feature request list is the nature of the category. Different products carry different requirements.

And the organizational point: close accounts knowing they will stretch you, because that is where the learning is. Close one without acknowledging the work it will require, and you are in for a world of hurt.

Building empathy structurally

Strickland's definition of empathy across functions is simple. Everyone's job is hard, just hard in different ways.

Sales is hard because you hear no repeatedly, and rewarding because you close and get celebrated. Customer success is hard in its own way, with difficult conversations that feel like rejection, and its own version of the win when you have genuinely delivered value.

What makes this operational rather than aspirational is the mechanism. The month of the recording, Productboard was running a hackathon in which every team was required to include a go-to-market participant.

Which means a customer success leader, a product marketer, someone from community, or a salesperson sitting in the ideation phase, building empathy both for customers and for what it actually takes to build product. And the reverse, because the salesperson in the room represents what is blocking deals and what a six or nine month sales cycle is like.

His other example is companies where everyone starts in support, answering tickets. You have to walk in their shoes.

Michael's version from Automattic is both: hackathons, plus every new hire regardless of function doing three weeks of customer support. You learn the product, you meet customers, and you find out how hard support is.

Gordon Ramsay and Elon Musk in a room

Strickland's crazy story comes from a company built at the intersection of food, delivery logistics and technology, which means three genuinely different professional cultures in one building.

They ran an interview panel with a scoring system from one to four. One meant: I will fight you if you try to hire this person. Two, no but I can be convinced. Three, yes but I could be convinced otherwise. Four: I will fight you, we must hire this person.

His description of the result is the memorable image. Picture a Gordon Ramsay type and an Elon Musk type in a room, fighting over a candidate. The kitchen mentality of this is my domain and I own this decision, against a technology CEO responding that this is his company.

Strickland inserted himself, calmed it down, and had to explain to a Michelin-rated chef what a four actually means. That you are fighting for this person because you fundamentally believe it. And that being accustomed to making every call in your own kitchen is not how this dynamic works.

It took two and a half hours to get people with entirely different experience onto the same plane to make one important decision. Referee, lifeguard, whichever analogy you prefer.

The 5 things I took away from this conversation

1. An ICP with three rings beats one with a description. The bullseye you serve well, the ring you will stretch into and co-build with, and the ring you refuse. Most companies only define the first and then argue case by case about everything else. Naming the outer ring is what makes it easy to decline a deal that will churn in six months.

2. Let each department write its own readiness scorecard. Greg's team spent three years moving upmarket on a scorecard that engineering and product wrote for themselves. The reason it worked is ownership. A top-down list of what each function must fix produces compliance at best.

3. Feedback is a sequence of questions. How will you know this succeeded? What are you judging it on? What number, over what period? Greg's point about compounding is the reason to bother: do it enough and people arrive already carrying the answer, and you become a sounding board instead of an approver.

4. Ring-fence what must be true, sprint on everything else. The way to survive constant reprioritization is not to reprioritize less. It is to be explicit about which initiatives are attached to the vision and therefore protected, so that everything outside that boundary can move freely without anyone feeling whipsawed.

5. Put a go-to-market person on every hackathon team. The cheapest empathy mechanism I have heard. Salespeople see what building actually takes, engineers hear what is blocking deals, and nobody has to sit through a workshop about collaboration.

FAQ

What is an ideal customer profile? A definition of the companies your product serves best, used to focus sales, marketing and product decisions. Strickland's version is a dartboard with three rings: the customers you already serve well, the ones you will stretch to serve and co-build with, and the ones you deliberately will not sell to.

How do you build an ideal customer profile? Start from evidence about which customers you already serve well and why, then decide explicitly which adjacent segments you are willing to invest in serving. The part most companies skip is defining the outer ring, the customers who would be unhappy and churn, so the organization has clear permission to decline them.

What is product operations? The emerging function that owns the product management system of record, drives insights from it, and runs the process of product management. Strickland places it in the same lineage as sales operations forming around CRM, marketing operations around automation platforms, and customer success operations around retention tools.

How does a startup move upmarket to enterprise? Productboard's approach was an enterprise readiness scorecard filled in by each department rather than dictated from the top, combined with a dedicated cross-functional pod around the first enterprise accounts. Strickland stresses it is a company-wide initiative, and that founder willingness has to exist before it can work.

How do you handle enterprise feature requests without derailing the roadmap? Look for consistency of signal across many customers rather than building for the loudest one. Strickland's warning case is the company that builds bespoke functionality for a single dominant account, then does not survive that account churning. The overlap in the Venn diagram usually resolves the majority of requests.

Also mentioned

• Productboard, its insights, prioritization and roadmapping modules
• Box, and the iPad launch that Aaron Levie turned into a company-wide directive
• Startup CXO and Matt Blumberg's writing, twenty years of it in Michael's case
• The Hard Thing About Hard Things, Amp It Up and Radical Candor, the operator canon Greg cites
• Salesforce, HubSpot and Gainsight, the systems that created sales, marketing and customer success operations
• Automattic's practice of putting every new hire through three weeks of customer support

Listen to the full episode

Greg Strickland on Between Two COO's

Between Two COO's is hosted by Michael Koenig. Subscribe on Apple Podcasts, Spotify, or wherever you listen.