Reworkshop

Even with the best intentions, domain knowledge, and solution knowledge, a team is only able to forecast accurately for up to three months of work. Six months is the maximum, but accuracy will suffer. Anything above and beyond is pure guesswork. This does not mean that you shouldn’t establish a product roadmap that goes beyond these initial gates.

To set up the project for success, always communicate up front that there are a number of variables that have an impact on the validity and accuracy of estimates—such as changes of dependencies, clarity of solution, feedback from the field, or change of technologies or industry. It’s worth reminding the client that the workshop uncovered likely up to 60 percent of the needed scope, and that further discovery will simply lead the team to a waterfall process. Focusing on delivering measurable, substantial value within months of starting is the focus. Once working software is in the hands of users, a more educated plan can be established for subsequent releases and needed features.

To manage the product in a meaningful way, the team reworkshops the remaining backlog using a quarterly cadence. This gives the team an opportunity to

• reflect on the previous quarter, taking into consideration what worked, what didn’t, any negative or positive patterns, where estimates were inaccurate, and delivery to date;
• prioritize the remaining backlog, prepare a roadmap and a release schedule for the next quarter, and revise estimates; and
• use analytics and data to make informed decisions on upcoming roadmap for product.

Managing risk when incremental releases are not viable

There have been times when we worked on projects that could not release into production on a quarterly cadence. A large SaaS product build may require a certain depth of MVP functionality before being released. A legacy application that is being refactored may need minimum feature parity before users can start switching over. These and many other scenarios introduce additional risk to the team for the following reasons:

• Significant investment is made without material outcomes. Client may get antsy without seeing results and feedback.
• Large scope is built without user validation in production. Overinvestment in features may happen.
• Market and business needs may change throughout the project life cycle.

You can probably tell that some of the above risks are unavoidable, but there are tactics to manage them. Consider the following:

• Push limited “friends and family” releases. Even if the product is not going public, consider a limited release to a select audience—perhaps a single real customer.
• Set and communicate project milestones. Publish significant chunks of functionality to a pre-prod environment, film product demos, and communicate to the stakeholder group when a component is feature complete.
• Challenge client strategy. Stakeholders will often be risk averse, to the detriment of the overall goals. Overinvesting and gestating a product for two or more years is normal. Establish metrics that can be measured and run closed-door user-testing sessions as early as possible; use gathered data to convince clients that a subset of functionality could be used for market release.
• Overcommunicate. Run additional demos, record tutorial videos, and create product presentation decks to circulate the progress and results delivered based on to-date investment. Spend fatigue is a real thing. Proactively manage the engagement and communicate the work being completed by the team.