How do you balance “shipping on time” with ensuring you have the right market insights to prioritize the roadmap correctly? We do 2 week sprints.

• Generally, I think about three fundamental dimensions in product development: time, scope, and resourcing. You will never be able to force all three to your liking, in most cases you will pick two, which in turn determine the third:
• If you have a team with a given size and you pick a ‘ship date’, you are implicitly making the decision that scope needs to be flexible (i.e., you will have to be OK cutting / adjusting what is getting shipped)
• If you have a team setup and a clear scope in mind, the time component will be determined based on bottoms-up planning against the required work (i.e., it will be shipped ‘when done’ for the most part)
• It’s worth recognizing that ‘shipping on time’ isn’t a standalone issue, but very quickly moves into a trade-off discussion with the other dimensions.
• That being said, when discussing scope, it is easy to get into ‘analysis paralysis’ of trying to find ‘perfect’ data/insights to support your product direction. There is no simple answer for ‘how much research is good’, but I like to use the following constructs to think through trade-offs and ensure I’m comfortable with the amount of unknown unknowns and associated risks before moving ahead:
• Definition of success: being clear on the desired outcomes/target state and how to measure success are critical. Not being clear on this item usually indicates that more research is necessary, otherwise the risk of shipping something ‘on time’ that’s not useful (or needs to be reworked) is high.
• One-way doors vs. two-way doors: without further research, will you need to make decisions that will lock you and your team into an irreversible path for future product/engineering work? If so, it usually makes sense to assess insights further to make sure that this won’t cause issues down the road. Two-way doors on the other hand (i.e., decisions that are easily adjusted/reversed in the future) keep optionality to iterate and might indicate that it’s worth shipping now and use this as an opportunity to gain more direct customer feedback/insights.
• “Crawl, walk, run”: sometimes it’s more important to ship small increments quickly to gain traction and learn more about your customers’ needs. It’s worth thinking about whether additional insights/analysis with the currently available information will be faster/give you more confidence in your product decisions than shipping something quickly that will allow you to iterate with customers and get direct feedback that way.

Ideally you have the right market insights before you start building. However, if you have open questions, I encourage you to break down the project into smaller milestones you can ship that help you answer those questions. This way, you are continually shipping, but they are smaller in scope, but also helps you de-risk when there's a lack of clarity in market insights. 

Job number one is ensuring you have the right market insights to prioritize the roadmap correctly. Engineering managers and scrum masters can pick up the slack and keep the trains running on time when you’re falling behind on customer research. Never shortchange market insights!

“Agile Research”

This is a term I coined to describe the act of always conducting user interviews. The problem with well-designed research projects is that they take too long and tend to deliver the insights after you’ve started building the thing. Advocate for a “rolling recruit” of your key personas so that you can tap into talking to users *every week.* This ensures you have feedback and insight in the moment you need it most before the product is built and decisions are made. Alternatively, you can create a type of Customer Advisory Board where members opt into research questions, providing feedback, etc on an ongoing basis.

Two week iterations are very common and can work effectively if you've broken the work down in such a way that you're delivering customer value within each sprint.

The question I have is: What does "on time" mean? If you're off by a day a week or even a month, that rarely matters. If yo'ure off by months (plural!) then you have not planned well. And yes, you need to plan. Nothing in Agile says don't plan.

You also should have done your research. I'm a big fan of Jared Spool's approach - get the up front research right and the delivery will be fine. That's because you'll have mich higher confidence you're shipping the "right" product to solve the problem.

Balancing "shipping on time" with ensuring you have the right market insights to prioritize the roadmap correctly is a common challenge in product development. Striking the right balance involves a combination of proactive planning, effective communication, and a continuous feedback loop. Here are some strategies I have used to achieve this balance:

1. Adopt agile methodologies that facilitate iterative development. Break down the development process into smaller, manageable cycles and continuously reassess priorities based on market feedback.

2. Focus on delivering a Minimum Viable Product (MVP) that addresses the core needs of your target audience. This allows you to release a functional product quickly and gather real-world feedback to inform future iterations.

3. Establish a continuous feedback loop with customers and end-users. Use surveys, interviews, analytics, and user testing to gather insights into their preferences, pain points, and expectations. This feedback should guide the product roadmap.

4. Leverage data analytics and user metrics to make informed decisions. Monitor user behavior, adoption rates, and other key performance indicators early to assess the market impact of released features and adjust quickly if you aren't seeing the signal you expected.

5. Use regular reviews of the product roadmap with key stakeholders, including market research, product marketing, and other stakeholders close to market insights. This provides an opportunity to reassess priorities based on market dynamics, competitive landscape changes, and internal considerations.

6. Use time-boxed exploration. Allocate specific time frames for exploring new features or products. This approach allows for innovation while also ensuring that exploration does not lead to analysis paralysis and delays.

7. Embrace iterative planning that allows for adjustments as market conditions change. Regularly revisit and update the roadmap based on new insights and business priorities.

By combining these strategies, you can navigate the tension between shipping on time and ensuring that your product roadmap aligns with the right market insights. Regularly reassessing priorities and staying adaptable to change are key principles in achieving this balance.

Balancing timely delivery with market insights isn't about conflicting goals; it's about ensuring we ship the most impactful solutions. Here are some best practices to achieve that:

1. Continuous Market Research: Make market research an ongoing effort beyond sprint planning. Monitor industry trends, analyze competitors, and gather user feedback regularly through surveys or interviews. Proactive effort is key to staying ahead.

2. Groom Your Backlog: Keep your backlog fresh by regularly reviewing and prioritizing items. With a steady stream of market insights, it becomes easier to identify the most impactful backlog items. Clear out outdated items to focus on what truly matters.

3. Iterative Development: Embrace the iterative nature of agile development. Break down solutions into smaller, manageable chunks to deliver and test in each sprint. This flexibility allows us to adapt to changing market conditions while continuously delivering value.

4. Feedback Loops: Establish feedback loops with stakeholders and end-users to validate assumptions and gather input on features. Utilize lightweight prototypes for early feedback and be willing to pivot based on insights. Testing and iterating are essential for delivering solutions that truly meet user needs.