Main menu:

Site search




Planning and Commitments (Or a Lack Thereof)

schedule One of the more uncomfortable negotiations between a product team and business people typically happens at the start of a project. This is where the business people want to know what the team can deliver so they can communicate to customers and investors and the team is looking for guidance as to what they should build.

This situation can get uncomfortable if one or both parties are afraid, unwilling, or unable to commit. The business people don’t want to communicate unrealistic plans and the team doesn’t want to be locked into an unrealistic schedule. As my friend Gerry Hawkins said to me in a recent e-mail, this could lead to an endless round of questions: “what do you want?” from the product team and “what can you give us?” from the business people.

Agree on the Vision First

Make sure everyone is one the same page at the highest level first. What are you trying to build? Who is it for? Why are you building it? Who are your main competitors, and what do you think they are doing or going to do?

If you can’t agree on the vision then there is no point talking about anything else.

Understand Value

The next level down from your vision is understanding what value you are providing to end users. In particular, are there any areas where your company / team can provide unique value that your competitors are not likely to?

Stay away from checklists of features to compare with competitors. What can you do that your competitors can’t? Can you offer superior consulting and support? Can you get your customers involved in your development? Can you use telemetry to provide a unique level of service to your customers? The goal is to talk about VALUE with customers, not features, because if your product is being compared with others solely based on features you’re in big trouble. This should change how you communicate with customers too, since it shouldn’t just be about features. And this should help take the pressure off the internal negotiations.

One technique I use to drive all our discussions is the idea of value streams. Every high-tech product or service has a number of areas where the team provides value. For example, in one of my past teams we focused on a small number of areas: visual quality (to improve realism) and workflows (so our end users could create compelling presentations without a lot of work). Your goal in each release is to make progress in each area, and make sure you have the balance right between these areas.

Note that you don’t always need to invest at the same level in each area; the advantage of keeping value streams in mind is that it helps you focus on what is most important to your situation and have discussions around how you want to invest in each area. You might choose in one release to have a big push on one stream, but that should be a conscious decision by your team. It’s too easy sometimes to let a heavy burden of work in one area overwhelm your team and take over, which would hamper progress in other areas. Do it consciously, don’t just let it happen over time!

Use a Kanban

Use a Kanban for your priorities. A kanban is great because it puts your priorities in a visible place where everyone can look at it. Make sure your kanban never exceeds the capacity of your team to deliver and that on the kanban you highlight the value streams in a visible way. And be creative! Use different colors for your unique value streams for example. That way, you can tell from 50 feet away whether you have the balance right between your various value streams.

As with the above items, have lots of discussions around your Kanban before you dive into the details around individual features. I’ve had a couple cases where we’ve used the kanban to do iterative planning, where in each iteration we go through the kanban, changing priorities, breaking down some items, putting estimates on them, etc. This helped us converge on a roadmap and proved to be an excellent way to capture our backlog too.

Write User Stories

Once your priorities are sorted out, write user stories for each feature and make sure the stories include some idea of completion criteria. This is essential to ensure that everyone agrees on what must be built.

Don’t Hold Back

If you still find yourselves going back and forth make sure that all concerns are in the open.

A common problem for the development team is technical debt: if the code base is hard to modify, doesn’t have adequate test coverage, and expensive to change then you need to get some work onto your roadmap to gradually fix it. A word of advice: when you do fix it make sure that the changes are driven by business need and not out of a purist sense of the code not being good enough because it never will be!

For business people, make sure that the development team understands the business. Do you need to make a profit quickly so you can get a new round of investment? If the development team doesn’t understand then how can you expect them to have the same sense of urgency?

If users are involved, make sure your concerns are heard too and that you believe in the user stories. It is critical that if you aren’t comfortable that you say so, and as early as possible!


If you still can’t agree don’t be afraid to iterate from the vision down as many times as needed. Keep talking and above all don’t give up!

Write a comment