When working on projects, I’ve come to the conclusion that there are (at least) three distinct levels to consider in everything that you’re doing. I call them “operational”, “product”, and “technical” and I’ll break them down further here.
Operational
- They don’t necessarily need to know or care about the Product milestones. In fact, I’ve seen a lot of wasted time and energy from Product folks struggling to convince Business folks that the Product milestones are meaningful or appropriate, when all the business stakeholder wants is their original end result.
- Be clear and collaborative on what the stakeholder’s Operational milestones are. It might be somewhat aligned with Product milestones, but they are often comprised of multiple Product milestones. Understanding these Operational milestones will be crucial to prioritizing the underlying Product milestones. If you don’t line these up well, you will end up doing parts of different Operational milestones, which won’t add incremental value. You will be forced to wait until you’ve accomplished more in order to get real user feedback.
- Be sure you’re completely aligned on the overall objective, and what is “good enough” vs “nice to have”. Sometimes stakeholders have been conditioned to ask for the kitchen sink because they’ve been burned in the past on not getting what they’ve asked for. You may inadvertently do this to them again, so make sure what you do deliver solves their core problem(s).
- At this level, you can mention what was more complicated than expected if timelines are running long, but in general, try to avoid getting into the day-to-day minutiae of the project. What the Operational stakeholders care about most is 1) is the project on track, and 2) if not, what can they do to get it back on track. Keep the conversations and updates focused, concise, and meaningful.
Product
- Product milestones tend to be the important to define in a project. Sometimes they are all you have to work with on smaller projects. They should be very aligned to business objectives, with clear measurements and expected impacts.
- Once the Product stepping stones are outlined, that’s when you can go up to align with Operational milestones / goals, and down to determine what Technical work (or discovery before the work) is required.
- Product Managers play a key role in this business-to-technical translation and most of the time they are the only ones that can see both sides of the equation. Meaning that Operators may not understand or appreciate all the technical work needed, and Technologists may not understand or appreciate the bigger picture vision that all their work is marching towards.
Technical
- On the Technical level, these are the individual units of work to be worked on by the team, either sequentially or sometimes in parallel.
- These units of work could line up 1:1 with a Product milestone but oftentimes there are multiple technical units of work to each milestone.
- This could include work required before beginning on a specific feature request, such as new database changes, desired refactoring to make the feature easier to develop, solving for inter-application dependencies, etc.
- I typically try to scope the technical work to be done quickly (2 hours to 3 days) and predictably, so they can be managed closely. Any delays in the technical work can cascade into larger overall project delays, so watch for and correct any slippage as it comes up.