Retroactive product alignment documents
Transitioning into alignment processes without missing a beat
As you first venture into building a product, alignment is straightforward.
Alignment is whatever the founder(s) has in their head. It's clear, because it's in their head. It's communicated, because it's in their head. It's evident, because it's in their head.
As the team grows, clarity dissipates. What ends up taking its place is not quite the exact opposite (murkiness?). It's more akin to a hydra; with each head representing a new individual's opinion of what each feature should look like and achieve.
Of course, we can't be havin' hydras running around our businesses. That's just not gonna fly.
Product insights delivered straight into your inbox. Subscribe now 👇
So, it's an interesting spot I found my company in a couple weeks back: lack of product processes, lack of alignment of the product as a whole, lack of understanding of the purpose of each feature and how they fit within the whole.
Not by anyone's fault, mind you. We've gone through the classic founders-led phase, the classic hiring phase, and now we're in the classic holy-shit-hydra-what-do-we-do phase.
I'm attempting to solve this with retroactive product alignment documents. Here's how I've set it up so far.
1. Pick a product alignment template
Product alignment documents (PADs) serve the exact purpose you'd expect them to serve: align your product.
Some people call them product requirement documents (PRDs). I find this doesn't tell the whole story nor displays enough of their value. So, I've gone with PADs.
After outlining what I'd like my PADs to look like and Googling a bit, I settled on Farbod Saraf's template he uses at Miro.
2. Start somewhere (aka retroactively)
I now had a beautiful template and a bazillion features I could start with. What to pick, what to pick?
Instead of panicking and 'start from the start', I decided to jump on the running horse. Is this not an expression? It is now.
I grabbed the three epics my team was currently working on and started creating the PADs. I made it clear to everyone involved that this was very much a retroactive approach to understanding and scoping the work they had already done; so no one felt blindsided.
This retroactive approach helped me learn a lot about the process I was attempting to put together. It also helped me get immediate feedback from the team through a real-life, 'right now' experience.
3. Build a framework
Eventually, every part of our platform will need a good ol' dose of alignment. I just can't do it all at once.
So I put together a simple framework:
Create a space for all PADs inside our internal documentation tool (Confluence).
Replicate our application's structure inside the documentation.
Add my first three PADs.
Look two-three sprints ahead in my roadmap and prioritise the feature we will work on.
Start creating PADs.
Repeat steps 4 & 5 until hydra no more.
With this approach, I can make sure I eventually hit all the important points while still providing value to my team.