Tooling (and AI, of course)

The market is overflowing with tools - AI assistants, collaboration platforms, analytics dashboards, niche SaaS products (with AI integrated!) for every imaginable workflow. It’s tempting to try them all. But tooling is not strategy. A good tool accelerates existing strengths; a poor one multiplies inefficiencies.

Some organizations love to collect tools like shiny objects. Every pain point comes with a new platform, subscription, or “quick fix.” And of course AI has entered the landscape by force, as chat but also wizards within other platforms. Some teams are being mandated to be using AI, so that the business is not “left behind”. The problem: tools don’t solve problems. People do. Tools only accelerate (or complicate) the work depending on how they’re introduced and adopted.

Effective teams treat tools as part of their operating model, not as shiny objects. They introduce them intentionally, guided by a few questions:

1. Fit — Does the tool align with the way people already work? If it requires people to constantly context-switch or feels like extra work, adoption will die fast. Tools should dissolve into existing habits, not demand entirely new ones.

2. Friction — Does it remove barriers or add new ones? Does it work for everyone on the team or just a subset of folks?

3. Focus — Is it solving the right problem, or just a problem? Does this distract from what we should be actually working on?

4. Flexibility — What’s the plan if the tool doesn’t work out? Too often, teams get stuck with tools that don’t scale or can’t integrate. Part of “trying something new” should always include the question: If this doesn’t work, how do we exit?
   

Organizations that answer these questions up front could save themselves months of rework and resistance.

Too often, teams focus on what tools to use instead of how to use tools well. A team that doesn’t know how to run effective meetings won’t suddenly become effective with an AI note-taker. A company that avoids tough prioritization decisions won’t magically improve by adding another project management suite.

The tools that truly stick for your team might not be the buzzy ones. FigJam for collaboration. Miro for brainstorming. ContentSquare for understanding behavior. Yes, ChatGPT for drafting and discovery. But sometimes a shared doc and a standing meeting are still the most powerful tools you can have.

The best teams don’t chase every new tool. They learn how to audit, experiment, and fold the right ones into their culture. That’s how tools stop being shiny objects and start being leverage.

---

STAND-UP EXERCISE

At your next team stand-up, run a quick tooling audit together:

• List the top 3–5 tools your team uses daily.

• For each tool, ask:

  • How does this fit into our flow of work?

  • What friction does it remove? What friction does it add?

  • Are we using it to solve the right problems?

• Choose one tool to experiment with improving. Compare notes on how each other uses it. Does someone need more training? Are there ways to be using it more effectively? Simplifying? Or a need to sunset it or an overlapping tool?

The goal isn’t to chase the next new platform. It’s to ensure the tools in use are actually serving the team, the process, and the outcomes.

Uncovering and Challenging Our Hidden Assumptions

Product teams constantly make decisions rooted in beliefs about their users, market conditions, and solutions. The challenge emerges when these beliefs remain unexamined—when teams operate as if their assumptions are established facts. In Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value, Teresa Torres highlights how teams must actively identify and test the assumptions that drive their product decisions, particularly those tied to meaningful business outcomes.

The risk lies not in holding assumptions, but in failing to recognize them as such. Unacknowledged assumptions become invisible drivers of product direction, potentially leading teams to build solutions for non-existent problems or chase metrics that don't actually matter. When assumptions masquerade as certainties, teams lose their capacity for genuine learning and user-centered discovery.

Torres advocates for connecting discovery work directly to desired outcomes, but this connection only works when teams honestly surface what they're taking for granted. High-performing product teams distinguish themselves by making assumption identification a regular practice, transforming invisible beliefs into testable hypotheses. Testing your assumptions is a much quicker and more repeatable process than testing new features. To test an assumption, you are simply looking for confirming or disconfirming evidence to support or dispute, which can prevent continuing on an unadvisable path.

Torres groups assumptions into five categories: Desirability, Viability, Feasibility, Usability, and Ethical. Grouping assumptions can help you see where your blind spots are, or in what ways you might carry bias.

Consider a recent feature your team shipped or is currently building. Chances are, it's built on a foundation of assumptions about user behavior, business impact, technical feasibility, and competitive landscape. Some of these assumptions may be well-founded, others completely wrong. Without a deliberate practice of assumption identification and testing, you're essentially building blindfolded.

---

STAND-UP EXERCISE

Choose a current project, feature, or initiative your team is working on. As a group, spend 15-20 minutes identifying the assumptions underlying this work. Use these prompting questions:

User Assumptions:

• What do we assume about who will use this feature? Does anyone want it?

• What problem do we assume this solves for them? How prevalent is that problem?

• How do we assume users will discover and adopt this?

• Is there any potential harm to our users in building this? (Think about data storage, categorization, user habits / dark patterns, disruption, etc.)

Business Assumptions:

• What impact do we assume this will have on our key metrics? Or will it support our broader business goals?

• What do we assume about the competitive advantage this creates?

Technical Assumptions:

• What do we assume about the technical feasibility or complexity?

• Do we assume this passes our legal / security / compliance safe guards?

• What do we assume about performance, scalability, or maintenance?

Market Assumptions:

• What do we assume about timing—why now?

• What do we assume about our users' current alternatives?

After identifying 8-12 assumptions, categorize them:

• Validated: We have evidence supporting this assumption

• Testable: We could easily gather evidence for this assumption

• Risky: This assumption, if wrong, would significantly impact the project's success

Pick the 2-3 most risky assumptions and discuss: What's the smallest test we could run to validate or challenge this assumption? Could we test it through a customer interview, analytics review, prototype, or small experiment?

Remember: This exercise aims to illuminate assumptions, not eliminate them entirely—that would be impossible and counterproductive. The value lies in making hidden beliefs visible and focusing testing efforts on assumptions that could significantly impact your project's trajectory. Torres' approach to continuous discovery centers on weaving customer insights into everyday product decisions, and systematic assumption testing provides a concrete method for achieving this integration.

This exercise works best when teams approach it with curiosity rather than defensiveness. The assumptions you uncover aren't failures—they're opportunities to learn and build better products.

Measuring Execution: Product Metrics, Part 2

In the previous stand-up we discussed setting a baseline around product metrics. This baseline simply maps out the current metrics that are gathered by the team, and begins to understand whether they are useful (not a vanity metric) and whether they are leading or lagging indicators.

After a current baseline has been found, metrics can be mapped to stages of the user’s journey. While not every product is one that results in a sale, the below chart can be used to understand what types of metrics can exist at each stage.

These example metrics are not exhaustive, and many more can be tailored to a specific product. Ideally, each product team can report on metrics from each of the user journey phases.

North Star Metrics
Many product teams subscribe to the idea of a North Star Metric. This metric is a single measurement that best captures the core value your product delivers to the user. The focus of a North Star is on retainable long-term user growth and satisfaction. This metric would be in your elevator-pitch about the success of your product.

Many successful product companies use a North Star Metric to keep their teams focused on their core value. For example:

• Google - clicking a search result

• AirBnB - nights booked

• Facebook - daily active users

• WhatsApp - number of messages a user sends

• Salesforce - average records created per account

• Slack - number of paid teams

How to figure out your North Star Metric

• something that indicates your user experienced the core value of your product (define your user's success moment)

• reflects the user's engagement and activity level

• something you have control over / can affect

• easily understood and communicated

• can be tied to product success / company success (aligned to your vision)

North Star metrics should not be swapped out frequently. They should meet the criteria above and then be given long enough to prove useful to measuring long term success.

---

STAND-UP EXERCISE

Ask your product team to map their baseline metrics to the user journey using the chart above. Is there one metric that stands out as the single best indicator of long-term value of your product? Can one of these metrics be your North Star Metric - both aligned to your vision and tied to company/product success?

Develop your North Star Metric and begin to watch it as a team. Is it something you have control over as you experiment and ship? If so, begin reporting on it to your stakeholders as your North Star, and holding yourself accountable to its outcome.

Measuring Execution: Product Metrics, Part 1

To consistently drive scalable and sustainable growth for your product, you are likely going to need to understand a set of useful metrics around your product or platform. At their core, product metrics are indicators that show how users interact with a product. But there are several types of metrics, and varying levels of utility.

There are two primary groups to metrics, leading and lagging indicators.

Leading indicators - tells you where your business is headed

• drive daily tactics

• measure frequently (and easily)

Lagging indicators - tells you if your actions were successful

• drives long-term strategy

• measure at a longer time interval (quarterly / annually)

Neither of these is “better”, they are simply used for different purposes on a different cadence. Your product team should be tracking metrics in both categories.

There are some metrics that are bad, however. These fall into two categories - vanity metrics, and metrics without context.

Vanity Metrics

• look good but don't measure meaningful results

• aren't actionable or controllable in a repeated way

• page views / "likes" / number of email subscribers

Metrics without context

• Often, running totals

• For example, "10,000 registered users" sounds good, but not if there are only "100 active monthly users"

To understand if you are working with vanity metrics, use this helpful worksheet from Amplitude.

Understanding the categories of metrics can help set a standard on gathering information about your product’s performance. Use the stand-up exercise below to help set that baseline.

---

STAND-UP EXERCISE

After reviewing definitions of leading / lagging indicators and understanding what types of metrics are bad, make a list of measurements the product team is currently using. Which category do these fall into? Are any of them vanity metrics or lacking necessary context to define success? Which of these measurements is used only internally to the team and which are shared out to stakeholders? How often have these measurements been used to inform a decision on the product?

Once a baseline is in place, the team can dive into making sure metrics correspond to each part of the user journey, as well as determining a primary North Star metric. More of that to come in part two.

Image by Freepik

Identifying Stakeholders

A key part of product management is managing stakeholders, as most teams require participation, guidance, and approval from a wide range of people across the organization. But oftentimes, product managers treat all stakeholders equally in terms of focus or time expended. A key component to effective stakeholder management is identifying your various stakeholders and grouping them by need. Having this knowledge will help your product team communicate effectively with these groups, and therefore gain early alignment on goals and plans, as well as address any conflict or risk early on.

Often stakeholders can be grouped by their levels of power and interest. A simple two by two can map these out - resulting in four groups: Players, Context Setters, Subjects, and Crowd. (This matrix was popularized by the book Making Strategy: Mapping out Strategic Success.)

The needs of each of these groups are different.

Players
High Interest, High Power
- need to be managed closely
- need high-quality data/insights regularly
- get buy-in on big decisions early
- ask for feedback often

Context Setters
High Power, Low Interest
- need to be kept satisfied
- they can influence the future overall context
- raise awareness with them
- could convert them to players?

Subjects
High Interest, Low Power
- need to be kept informed, "read only" stakeholders
- make use of their interest through low-risk areas of involvement
- "goodwill ambassadors"

Crowd
Low Interest, Low Power
- not worth time to actively manage
- inform via general communications
- aim to move into Subjects

How you interact with these groups in form of the cadence, information provided, and size of audience will all vary. But it is important to keep these general needs in mind, as the more you can tailor communication to gain support or approval from various stakeholders, the more likely your initiatives are to succeed.

---

STAND-UP EXERCISE

Have your team do a stakeholder analysis by first listing all the groups (or individuals) they know to be stakeholders for your product. Then work to sort these folks into the 2x2 matrix, paying attention to both the level of power and interest. After their needs are identified, the product manager and team can begin to create tailored communication plans, focusing on building and maintaining trust with each of the groups.