Moving your from discovery to delivery as a product manager can be tricky! Sometimes it’s hard to know how to move forward and when the time is right. I like to follow Jerin Stewart’s advice on this and to move into delivery when you have no more than 70% of the info you need, and no less than 40%.
For discovery, I, and many of my colleagues, like to use the method for product management outlined in Marty Cagan’s Inspired. The basic premise is that you should do very deep discovery before moving a project into the delivery phase. The reason for doing this, is to answer these four questions below before moving to delivery.
- Will the user buy this (or choose to use it)?
- Can the user figure out how to use this?
- Can our engineers build this?
- Will our stakeholders support this?1
Sometimes it’s tricky to know when to move from discovery to delivery however. Once you’ve figured our the answers to the questions above, and the project passes them, how do you tactically move to delivery? I like to follow more-or-less the same steps for every project.
The process
- Write the epic This kind of goes without saying but the first thing I do is write, or re-write, the epic for the project. This means making sure the story is sound and all the acceptance criteria is captured. I’ll also add any note I have about the project and encourage the designer and engineers to do the same.
- Success metrics This is something that I’m always trying to get better at. I’ve found lately, that adding success metrics to my epics as early as possible helps! This gives me plenty of time to make sure they are the right ones. Perhaps more importantly, it gives me time to have my peers, our product analyst and the engineers review them. The reviews make sure that the success metrics are the right ones, we can actually measure them properly and we have the tickets in our backlog needed to make sure we can measure them, if we need to add anything from a technical perspective.
- Story mapping Story mapping is an invaluable tool to make sure all of the stories that belong in the epic are captured. We usually do story mapping with the whole scrum team, as well as key stakeholders to make sure we’re capturing every important story we need. After story mapping is complete, I’ll put the tickets we agreed are in scope into our backlog. Then I’ll start fleshing out the acceptance criteria for them.
- Technical story mapping After a more traditional story mapping session, I’ll usually sit down with our team’s tech lead and do a more technical story mapping session. She and I go through the story map we created as a team and find the technical gaps we need to fill in order to get achieve the stories. Often a lot of these will come out in the original story mapping session, but this final step ensures that we have as much of the work on our backlog as we can foresee before starting the project. This is alway where we add spike tickets to make sure we’re working ahead to address uncertainty as needed.
- Estimation The last step is of course, estimation. We do this as a team, and like any other product manager, I don’t participate. (It is not the PM’s role to decide the effort involved in doing the work.) If starting the work on the epic is far away or very uncertain, we’ll t-shirt size first. Once we’re closer to the start time or have completed some spikes, we can then estimate each ticket. This, combined with our team’s capacity, gives us our estimated date ranges for the work.
I find following this rough process helpful to get the team moving to the next step. Having steps laid out can really help stop analysis paralysis, because you know what to do next.
- Cagan, Marty. (2018). Inspired. (2nd ed.). Wiley.
Kate Moore Hermes 