Understanding if your product can help enterprise organizations

Articles ¡ Source

Most useful points

Understand the serious of engagement

Does the company want to use your tool for a mainline activity or a new, vanity project? Also, are they facing real problems or are they just a monopoly where a new person is trying to use a service to show "innovation" to their bosses?

Understand if they will use your product for the long haul

Or if their business model/strategy change soon and they'll stop being serious about your offering?

Understand the risk taking and learning culture in an organization

Is this an organization that wants to take risks to learn from them (loads of things that they tried and failed with), or is this one where failing is a death knell and so the organization plays it safe?

To do this, ask questions like ‘how often do your experiments fail?’. Not enough experiments that fail = company isn’t taking enough risks

Or “tell me your last 5 big product decisions” — speed at which the product leader is able to answer will give you information about a) how quickly does the org ship/learn/decide? b) who has decision authority, c) how they think. If they have to pause to remember, it's likely they have not shipped recently, or perhaps the person is not very in tune with the org, and so on.

Also understand how comfortable they are with uncertainty.

Do they have a structured approach to the known unknowns? A good product team has productive things to say about what is unknown ("we know this feature would do well, but we're not sure about that feature, but we have experiments going on for it"); a bad product team talks in generalities about the future.

Notice if your customer is naive

Is your customer enamoured by product frameworks but is yet to put them to practice? This is usually a signal that they are still novices. “Good product people put all these things to practice (from the frameworks), but they don’t talk about the frameworks. It’s just something they do”.

Ask powerful questions

Powerful questions are questions that are: neutral, have no right or wrong answers, do not pass judgment, but ‘crack the problem at the biggest spot to understand what is going on in the org’, and usually ‘nail a tradeoff or polarity between two opposing forces’.


Step 1: Understand the organization's past and future

You have to be able to quickly tell how the org got to its current state, and predict what problems it might be facing going forward.

To do this, always detect anti-patterns first. “Bad orgs all kinda look the same, good orgs can succeed for very different reasons.” Then, work backwards from the anti-patterns to figure out how the org got here.

Additionally, detect if there is high Work In Progress (WIP). Usually this presents itself with symptoms or complaints like ‘low morale’, or ‘no growth mindset’, or ‘no learning’. Use these complaints to figure out if the team has high WIP — which is nearly always a sign of a problematic product org. If high WIP exists, work backwards to figure out how the org got there.

Why is this hard?

  • Diagnosing how an organization got there is difficult
  • Also difficult because ‘bad’ practices might not be really bad, and must be evaluated within the context of the org.

Step 2: Understand the organization's big picture

Rapidly construct a gestalt that includes a number of factors, like: decision authority, decision power and structure in the org, org culture and demographic (country) culture, structure and workflow of the department you're selling to, org ability to learn, existence of product strategy and business model.

Decision Authority

First, understand decision authority within an organization. Who really holds the power in the organization? What is the shape of the decision authority, and how many stakeholders are involved when making a product decision?

  • ask questions to clarify if a product owner really has final authority over product decisions
  • where does this org lie on the extremes of product ownership? One extreme: product team owns $20m worth of business. Other extreme: product team has to have 5 meetings and 3 stakeholder sign-offs for a new ticket to be created in Jira.

Organization's Learning Ability

Then, determine an organization's learning ability. Is the leader/team comfortable with uncertainty? Can they talk about current hypotheses and experiments in play?

Ask questions like “tell me your last 5 big product decisions” — speed at which the product leader is able to answer will give you information about a) how quickly does the org ship/learn/decide? b) who has decision authority, c) how they think. If they have to pause to remember, it's likely they have not shipped recently, or perhaps the person is not very in tune with the org, and so on.

Also ask if they share knowledge within the company and across projections, whether the product team has direct contact with the customers etc

Seriousness of engagement

Next, evaluate the seriousness of product engagement — if the company wants to use your tool or another tool (for, say, analytics) check if this is a mainline activity or a vanity project – instead of being impressed by the absolute budget size. Conversely, if a business says they have an analytics problem, but they’re making a lot of money / are in a monopoly position in the market, they don’t really have a problem and may not use your product intensively.

Business Model

Check how the business makes money, in order to judge how important the product team is to the business.

Predict how a business model change will impact the product/eng teams, e.g. a business model change away from a high SEO, high traffic web product would mean changing the experimentation framework, doing less A/B tests, relying more on qualitative data, which means preparing the teams to switch to this new mode of learning and operating.

An expert will know and appreciate the role of luck in finding and executing a successful product strategy.

An expert will understand how a business model mismatch might affect org structure and impact various teams throughout the company.

Risk taking

If a company and product team is doing extremely well, ask ‘how often do your experiments fail?’.

Not enough experiments that fail = company isn’t taking enough risks

An expert knows that companies have good times and bad times, and not taking enough risks may bite the product team when the company goes through a bad time.

Org culture

Is the company centralised, where HQ sets the culture and local teams don’t get a say, or is HQ more hands off on culture and local teams can set their own culture? This is a trade-off that experts can quickly identify.

An expert will also be able to gauge if the org culture can produce psych safety, even though there are many different types of org cultures (e.g. company is toxic except for product team)

Expert also has large sample of org cultures that exist out there (e.g. some companies you can move freely between teams, some companies you cannot).

Product strategy

Check, in the following order:

  • is there a strategy or not?
  • is it halfway plausible or not?
  • is it implicit or explicit?
  • Is the structure of the company aligned around the strategy of the company/product?

An expert will know when to dig in to tell if the product strategy is plausible. It should be concrete, and centered on real world knowledge, and not fuzzy.

Step 3: Notice the little things in the organization

Pick up on attitudes and worldviews held by teams. Be able to place them on a spectrum of organizational health, based on a large n of observed organizations.

Notice a team's comfort with uncertainty

Do they have a structured approach to the known unknowns? A good product team has productive things to say about what is unknown ("we know this feature would do well, but we're not sure about that feature, but we have experiments going on for it"); a bad product team talks in generalities about the future.

Notice when a company has flow

Flow describes when a company is executing and learning smoothly. If they are rapidly moving through the execution cycle while being agile and can change directions in response to new information. (Related to the ‘walk me through five of your last big product decisions’ question)

This is a complex thing to notice. Breaks it down some of the cues you notice as “do they have high decision quality, high decision flow; do they have available and excessive data, do they have clean data, do they have the ability to interpret the data, the ability to link cause and effect, do they have enough data, do they have diverse perspectives, do they have the information they need to operate, are they able to make sense of it and align on it, and build coherent shared understanding, can they harmonise decisions and missions and can they find a compelling, overarching story or strategy.”

Notice if your customer is naive

Is your customer enamoured by product frameworks but is yet to put them to practice? This is usually a signal that they are still novices. “Good product people put all these things to practice (from the frameworks), but they don’t talk about the frameworks. It’s just something they do”.

Step 4: Ask Powerful Questions

Ask the minimum set of questions that generate the maximum set of insights.

Questions that cut through the mess

Powerful questions are questions that are: neutral, have no right or wrong answers, do not pass judgment, but ‘crack the problem at the biggest spot to understand what is going on in the org’, and usually ‘nail a tradeoff or polarity between two opposing forces’.

Example of a weak question: ‘please tell me about the M&A that you do’, vs a powerful reframing: ‘given your pursuit of M&A at this particular moment, talk to me about the centralisation and decentralisation of your services to support that.’ and ‘it seems your company is really good at logistics, but what did it give up to get there?’ and ‘tell me about the last five consequential product decisions that you did’ (inability to tell what these are, off the top of their heads, should tell you something about the structure and velocity of the product team).

Powerful questions will provoke a thoughtful answer from a senior person who is a good systems thinker. Junior people will give ‘softer’ answers, that are less multi-faceted or thorough.

Use humor to get a reaction

Humour opens up the conversation and allows you to ‘cut through the bullshit and get at the heart of the matter’.

e.g. If joke about quarters being weird, see how people react to that. It shows you how they feel about quarterly planning cycles, and if there are problems there e.g. if they keep changing direction every quarter.

Show visual guides

Show visual guides to provoke reactions and test for systems thinking ability. If they do not respond well to a concept map or flow chart, it is likely they are not a good systems thinker.