A collaborative, agile approach between Product and Engineering enables quick delivery of new functionality. This 7 step process is what I’ve used and continue to refine. What’s important to you and your teams may vary slightly.
Identify need
Product first has to identify the need and work through the following questions in the initial discovery of a project.
- What problem are we trying to solve?
- Determine actual need underlying a stakeholder request (i.e. 5 Whys)
- Why is this problem important to solve?
- What business objective does it help achieve?
- In what ways can we solve the problem?
- Who will be affected by this change?
- How do they use the product today?
- How do we want them to use the product in the future?
- How do we measure the impact of this change?
- What does a successful outcome look like?
- What systems does the change impact?
- What dependencies do we need to consider?
- Third-party applications, system integrations, data reporting, etc
Define scope
Once Product wants to move forward with a project, they must then break down the ideal end state into meaningful phases to add value as quickly as possible and begin learning from its usage.
- Break down large changes
- Each story should be an independent, releasable feature that incrementally adds value
- Layers of a cake vs. pieces of a cake
- Own the outcomes
- Product determines whether something adds value
- Product decides what to build based on their evaluation of the need
- Engage engineering effectively
- Work with engineering to assess feasibility
- Don’t use the story as a starting point for technical design discussions
- Don’t lean on engineering to provide solutions to business problems
- Don’t make assumptions
- Engineering does not always have the same business context that product does
- How something will be built isn’t always based on how it was done before
Draft requirements
Now that Product has its phases, they can begin gather and writing their requirements for the engineering team(s).
- Outline outcomes, not an implementation plan
- Highlight what should happen in success and failure scenarios
- Include metrics for evaluating success
- Don’t be overly prescriptive
- If it’s a bug, include steps to reproduce it
- Communicate clearly and concisely
- Don’t paste in emails from other stakeholders; ensure there’s a shared understanding
- Summarize what we are trying to accomplish and why
- Length does not equal clarity
- Don’t create a story if there are outstanding decisions to be made
- Keep all audiences in mind
- Engineers should have what they need to develop without much (if any) clarification
- QA should be able to verify that changes were made successfully
- Other product managers should be able to understand what changed and why
Develop & Test
With proper scoping and requirements, engineers should spend a vast majority of their time continually focused on actual feature development. Product should always be working a couple weeks ahead of Engineering to maintain a steady stream of prioritized and meaningful work.
- Develop small features independent of one another
- Smaller changes enable us to “fail fast”, gain quick learnings and evolve
- Features can take additional time to be less risky and higher quality if needed
- Easier to triage and rollback any critical release issues
- Focus on work that Product prioritizes
- If priority needs to change, reach out to Product
- Ask Product for more work
- Proactively reach out when workloads are light
- Don’t create busy work
- Collaborate with Product
- Negotiate scope when more efficient methods of meeting the need are discovered
- Flag any blockers or clarification gaps for product to address
Release & Iterate
With robust team processes and release automation, releases and next steps should be managed entirely by Product and occur often. I’ll write another article about my release philosophies soon.
- Coordinate releases
- Product and Engineering should be shepherding their stories through the sprint with a sense of urgency
- Assigning a story to a sprint is not the end of the process
- Product owns the execution, not just the strategy
- Support engineering to ensure the work gets done (eliminate blockers, simplify scope)
- Work with engineering to push out a release as soon as possible
- Releases can occur at any point and multiple times a day
- Product and Engineering should be shepherding their stories through the sprint with a sense of urgency
- Communicate with stakeholders
- Communicate estimated target dates with stakeholders ahead of time
- Let stakeholders know as soon as changes are released
- Coordinate training efforts or materials, if needed
- Verify outcomes post-release
- Make sure it is working as expected
- Measure the impact of the change over time
- Determine next steps