"Just throw it over the wall"
Is that how hand-offs happen in your company?
When your engineers start work, do they find:
😡 Product questions that need to be resolved?
😤 Requirements that are not fully cooked?
The good news is:
😎 Once you've batted the issue back over to the other side, you'll get a few days' quiet until it comes back.
Playing ping-pong with requirements is common in many organisations. It delays delivery, and lengthens the lifespan of issues (lead time or cycle time).
Don't attempt to fix this by instituting formal definitions and templates. This bureaucracy will help in the worst cases, where the problem is a lack of diligence. However, if your product managers are reasonably competent, this will make things worse.
The fundamental problem is usually a lack of collaboration. Requirements should not be prepared in a vacuum and then handed off to the engineering team, waterfall-style. Instead, they should be formulated in close collaboration with engineering. With good collaboration, there is no "other side of the wall" — you're all batting for the same team.
Handing something off between one team and the next should be an overlapping process. Just as the product manager is involved, informed and aware of issues during the implementation process, relevant engineers should be involved during appropriate phases of the requirements process.
Product Managers:Â
- Start cooking requirements well in advance.
- Give requirements a longer incubation period.
- No handed-off requirement should surprise engineering.
- Share with engineering well before you write formal requirements.
Engineers:
- Ensure that nothing handed off from product should surprise you.
- Don't expect perfect requirements to fall into your lap, waterfall-style.
- Help product understand the challenges and trade-offs you might face.
- Help product formulate requirements that you can realistically implement.
The way you choose to implement this will depend very much on your existing processes and company culture.
For the more strategic features or complex implementations, I start off with a Brief. That's my fancy name for a brain-dump, and it is therefore a rather informal document.
The 3 Goals of Briefs:
- Inform people about what will soon be coming down the pipeline.
- Â Serve as a focal point for getting input and especially questions.
- Attempt to uncover hidden problems before development starts.
Brief Structure:
I use a minimal structure, and modify it based on common sense.
- Background
- Problem
- Proposed Solution
Anyone can comment on a brief, though I typically also designate specific people to reserve time to review it.
Remember, it's an iterative process. You'll need to keep the discussion alive through the iterations.
After a few volleys of comments, revisions, and occasionally synchronous discussions, you may find that the process achieves one of the following results:Â
- Great solution! This is how we'll need to implement it.
- Great problem! Not so great a solution. Here's a better one.
- The problem is not the problem. We need to solve a different problem.
Why do features take so long to ship?
"Can you help me?"
Yes, my mission is to help clients to transform their engineering outcomes.
🤙 Contact me via my LinkedIn profile.Â
🤙 Contact me via my LinkedIn profile.Â
Thank you for reading this far!
__________