Time Estimation

Estimation is becoming harder. Figuring out how long a given task might take has always been a little fraught, as many organizations have an expectation of speed, but with the advent of new AI tooling, there are more unknowns. But estimation is as important as ever in the product development process.

Estimation does three things for a team:

1. Provides transparency

2. Opens up a conversation

3. Reinforces prioritization

First, providing estimates on work gives information to the team and stakeholders, making the process more transparent and generally collaborative. Your stakeholders have more realistic expectations about when a feature they’ve requested might launch. Product managers and scrum masters know when to check in with the development team without being intrusive. It removes an element of surprise from everyone.

Secondly, delivering an estimate on a piece of work begins a conversation. Questions about if elements are included or not can be answered. Information about if that fits into the timeline of the larger epic or campaign or project can be given. Complexity or dependencies can surface earlier, instead of waiting until they are more emergencies.

Third, understanding how long work might take gives clarity to how necessary the work is. For both the product team and the stakeholders, the question can then be asked, given this amount of time and effort, do we want to continue with the work as is? Or is something else best suited to begin now? Estimations can help clarify if we are on track for the goals of the product.

Estimation does not always need to be rigorous. Words like “ballpark” and “t-shirt sizing” are appropriate when talking about work to be done. Story points are more exact and often used, but also have their dissenters. The important part though is the dialogue that comes from the act of estimation and delivering that estimation to interested parties.

---

STAND-UP EXERCISE

In your product team, review your estimation process. Is everyone on the same page about how estimating work happens, where it is logged, and what to do when/if estimates change? Talk about examples of when presenting an estimate to a stakeholder changed the work - was it de-scoped or expanded, were complexities discovered, did the overall project take a different shape?

If you have been tracking estimation over time and have begun to use AI tooling, is that changing the way that you estimate?

For your team, when are estimates presented to stakeholders and how does that conversation emerge? Are there opportunities to improve that process and relationship?

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.

Choice Always Exists

Depending on your organization, and the placement of your product team within it, product leaders can sometimes feel that they lack autonomy of choice. Marty Cagan terms teams that just receive delivery assignments and must churn output as feature teams. These feature teams are beholden to business stakeholders, and often receive prioritized lists of features or projects that must be accomplished. They lack much autonomy in their work and timelines. This is of course in contrast to an empowered product team that is focused on the outcome of solving user problems in ways that create positive impact for the business. 

However, even the most mature product team in a user-centered organization can find itself with a directive, or even just a strong ask, from an influential stakeholder. In these cases, the product team will often say something like, "we don't have any choice". In their minds, there is no way out of delivering what they were asked, and so there is no choice to be made. The request for this feature came from the general manager of that vertical, or everyone knows this is the CEO's pet peeve that must be fixed, or the sales team has already promised it to a high-performing customer. Those are all reasons to complete the work as requested, but they do not preclude having a choice.

There is always a choice to be made, but what needs to be consciously factored in are the consequences. Instead of assuming there isn't a choice, instead think through the scenarios. The most obvious is completing the request as assigned. But what happens if the request is NOT completed? Does someone get removed from the team or worse, lose their job? Or is someone annoyed and good will is lost and a relationship is damaged? What if a different solution was presented - an MVP of the feature, or an A/B test, or a different delivery timeline? Who is affected and to what extent? What are the known consequences and potentially unknown consequences? Will your leadership support you in your decision? 

Often when we say, "we don't have any choice", we mean, "I'm unwilling to accept the assumed consequences". But when we take a further look, mapping out those consequences, perhaps we can think differently. Or at a minimum, we can complete the task consciously understanding the trade-offs. 

---

STAND-UP EXERCISE

With your team, think back to an instance where the team felt they didn't have a choice in completing a project or delivering a feature. Do a retro of this instance. What were the consequences that were avoided at the time? Were there alternate paths with different consequences / outcomes that were not considered? With the benefit of hind sight, would the team have acted differently in this scenario? 

Remember: as with all retrospectives, these conversations should be blameless - this isn't about pointing fingers at people in the past. Focus on the problem and events, not people or personalities. 

Book Club: Impact First Product Teams by Matt LeMay

Impact First Product Teams by Matt LeMay shows you the keys to impact right on the cover:
Define Success.
Do Work That Matters.
Be Indispensable.

Matt’s entire thesis is how it doesn’t matter how well you are “doing product” - you need to be consistently showing business impact for your team to feel stable and valued in your organization. He states, “Simply put, choosing to be an impact first product team means recognizing that our responsibility is ultimately to contribute towards a successful business.” Most organizations are set up to perpetuate low-impact work, but we can break the cycle at the place where the work is getting done - in the product team.

While this can be seen as a bit more of a philosophy book in that it is about changing a mind-set, he provides clear action items on how to move toward thinking about impact first, aligning to company goals, how to estimate potential impact when prioritizing work, and how to work towards cross-team collaboration.

Some key takeaways that would be good to discuss as a product team:

• One of the most powerful questions comes from Chapter 1: “If you were in charge of the company, would you fully fund this team?”

• Has our team adopted ways of working from another company, like the Spotify model for example, or have we purpose-built our own ways of working that help us achieve our own goals in our own specific context?

• What does success mean to our particular business? Thinking about viability in terms of does this create impact for our business model, how do we define viability for our product? How can we keep our team goal as close as possible (one mathematical step or one “why” statement) to our company goals?

• What is the most impact we could reasonably expect from the work we have in progress? Is that enough impact for us to continue the work? If we aren’t sure, are there signals we can look for or faster experiments we can run to better understand if we are going to be successful?

• How can we better frame up urgent requests from our stakeholders as a jumping off point to understand what might be complex or changing circumstances? How can we structure the discussion to learn about shared goals and create alignment?

Matt provides resources for product teams, which also make for good discussion materials. One of the best ways to begin the journey to being an impact-first product team is simply to begin having these conversations.

---

I was fortunate enough to meet Matt at an executive roundtable for product leaders last month here in Chicago, and then won a copy of his book for an up-voted question I posed. In the passing weeks, I’ve much dog-eared the text as I think through and discuss these topics with other product folks. The book is a quick read, but could have very lasting consequences for product teams within any organization. Highly recommend.

Product Vision

A product vision aligns the product team to the change you want to see - driving strategy, priorities, and execution. For teams where the product is the transactional item or service, this is likely an obvious one-to-one with the business or corporate vision. However, for those product teams working on internal tools or enabling platforms or secondary offerings, a specific product vision will need to be crafted.

A product vision statement should be:

1. Centered on the problem to be solved

2. Descriptive of a tangible end state you can visualize

3. Meaningful to you, and to the people you intend to impact

In Product Leadership, the authors describe, “A vision isn’t a poster on the office wall or a weekly newsletter to the team. It’s a concept of what the future will look like with the energy to back it up and something that should be regularly communicated to the team.”

A good vision statement should answer four questions, according to Radhika Dutt in Radical Product Thinking.
WHO - whose worlds are you trying to change? Who has the problem?
WHAT - what does their world look like today? What are they trying to accomplish and how are they doing that?
WHY - why is the status quo unacceptable? Why is it imperative to solve the problem? (Make sure that it is.) What are the consequences of not solving it?
WHEN - when will you know that you have succeeded?
HOW - how will you bring about the change? (This creates the actionable part of the vision.)

Those questions can be thought of in terms of a fill-in-the-blank vision template.

While a vision statement can include more, this template is a great place to start. Then, with a vision in place, you can support it with a set of guidelines to filter decisions/prioritization, and be confident your product team is aligned on what success is and how to get there.

---

STAND-UP EXERCISE

Work with your product team to brainstorm answers to the 5 questions above (who/what/why/when/how). Use consensus to translate those answers into the vision template. How does this statement compare to previous/earlier vision statements that might exist? Does this statement need to evolve to encompass more needs or users? How can you make it most useful to the team as whole?
Once complete, place this statement within your artifacts - add it to your roadmap, put it at the top of your Confluence, create a Teams background. Make sure it is often seen and referenced.