Simple Framework for Product Development: “Past, Present & Future”
I often like to frame product development as 3 buckets — Past, Present and Future.
- Past: What are the things we have shipped previously and how are they performing? Are our experiments achieving what we hoped they would?
- Present: What is the current sprint or work we should be doing today? What have we achieved this sprint and how is our product health looking right now?
- Future: What’s next? — basically the crux of backlog prioritisation — what opportunities should we be looking at next? What’s upcoming on the horizons? Do we need to tweak the roadmap?
I’ll give you some examples of how this is realised day to day.
The Wall
Visualising work is great! Whether you do this physically or use some kind of digital tool I’ve often broken the board down into these buckets — me personally I’m a huge fan of physical and love to divide the product team’s space into these buckets.
Working backwards, from left to right, just to confuse the hell out of you — Future, Present and Past:
- Future is our backlogs, both development and opportunity backlog (I’m a big fan of Jeff Patton’s dual track). It contains all of our potential future work, it’s basically our runway, from idea to discovery — we also had our current OKR above the Opportunity backlog as a reminder of our higher goal.
- Present is your typical Scrum/Kanban board/Sprint backlog — where the rubber hits the road — essentially from discovery to release.
- Past is the things we had released in previous sprints. I like to use Hypothesis Driven Development where just about everything outside the opportunity backlog are written as experiments. This means that for just about everything we release, we would have measurements against them. These measurements are our way of determining (rough-art) whether the feature (or whatever) we ship is achieving the outcome we expect it too or not — if not, also great, we pivot and try a new experiment! Basically in this bucket we have a bunch of metrics and features which we have shipped and are tracking their performance.
VP of Product/Group Product/Portfolio level board
For those who are working at scale (or thinking about it) this is your next level up board, a portfolio or product group level (or even multiple levels depending on the size of your org). Nothing revolutionary, basically your team level board but at a higher level of detail with the possibility of swim-lanes or something to denote the multiple products/product areas within the product group.
The board above I actually had little involvement in the initial set up (I like to just think I coached the Head of Product well 😅) but it’s one of the best photos I have of one of these boards — really gotta get better at taking photos at work! — fun fact too, this board actually had a more specific function than most product group boards I’ve done in the past. This one was particularly focused on any large cross-cutting initiatives but also on adjacent and “moonshot” bets across the product group, which is why you will see that the Present part commandeers a very large amount of space and you’ll also likely notice that it is heavily product discovery focused.
But all that aside, you can see how the team level board simply scales up (if required) and how it’s totally applicable for even VP’s of Product to still be thinking in these three buckets — as I say to those in that position I’ve coached, you’re still a Product Manager at heart, don’t lose those skills — (putting the responsibility of coaching your Product Managers and Product Teams aside) such skills are still very necessary and applicable at the VP level — you just now have the added complexity of multiple products to deal with so you sometimes need to get a bit creative in how you apply them.
Sprint Reviews/Showcases/Demos/etc style events (whatever the hell you call them)
I personally like to run sprint reviews following this past, present and future format. It brings great structure to the review but also I find it provides a holistic view of how the team and product is doing.
Typical format will look like this:
- Welcome, thanks for coming — blah, blah, blah…
- Kick it off with a look at the past first — this is typically data talk, we show and discuss our findings, both quantitative and qualitative. We talk about how previous features and the overall product have been performing. Think, lots of verbatim quotes from user interviews and a bunch of dashboard metrics showing A/B tests, features and product performance.
- Second is present — this is your typical what we achieved in the current sprint stuff — the hands-on, show me some real working software action! I also like to get the team to touch on any major highlights and lowlights of how the sprint went for visibility — often a lot goes unsaid and unheard and I’m a big fan of radical transparency!
- Finally we finish up with the future — essentially, what’s next? This is discussing both from a discovery and build point of view, we will talk about the problem space we are looking to understand more about next, as well as what hypotheses we are looking to ship next.
Stakeholder Management (and just general Product convos)
I also use this for stakeholder management. Think of a dialog with a stakeholder, whether that is face-to-face conversations of an email or text, following the same format as the above Sprint Review.
- Start with the past — how things are going, how is the product performing, how are your experiments going, etc.
- Next, the present — what the team is currently focused on.
- Finish with the future — what you and the team plan to focus on next.
I’ve found that this covers most if not all the ground which stakeholders are typically interested in. Often too I’ve found that they appreciate the visibility of the past component — how are our hypotheses performing? how are we tracking towards our goal/OKR? Often the focus in these conversations (at least in my experience) is weighted too heavily on the present and future parts — what are you doing?, aka trying to keep people busy 🙄 — when will x be done by? 🙄🙄 …always with the deadlines! — ok, perhaps a little over-exaggerated and simplistic but you get my point.
Buuut, if you are being asked these questions, besides being extremely dysfunctional, following this past, present, future format might help shift the conversation and hopefully over time, shift the culture towards outcomes over outputs.
Often, I find we are too busy in the now and worrying about the future that we neglect perhaps the most important part of the equation — what we have already done and whether it has achieved the outcomes that we hoped it would? Placing an emphasis on it and weaving it into conversations helps shift the dialog to be more outcome centric. No longer are we throwing things over the fence and forgetting about them, we are constantly cycling back and setting that expectation with our stakeholders and anyone else we have conversations with that it’s about achieving outcomes not just doing stuff.
Pro tip: Try to weave it into as many conversations and thoughts around your product as possible, the aim is to make thinking about these three a habit — or in other words try to be always thinking, how are the things we’ve done in the past performing, how is the product doing? What are we doing now? and what are we planning on looking at next?
Wrap up
Nothing revolutionary and extremely simple to follow. Personally this framing resonates well with me and it’s often one of the first things I will cover with the Product Managers I coach. Really it’s common sense and all things you should already be doing as a Product Manager but in reality I have often found that we do the Present part well, we’re ok at the Future stuff but we really suck at the Past.
This gap is often unearthed very early on when I start at a company as I start probing and asking questions like, what’s your vision/goal/outcome you are chasing and how are you measuring progress towards it? How are your users using your product and what major problems do they have? What is your conversion like? Retention rate? Are people using the features you just shipped? etc. their struggles to answer such questions reveals all — at least struggle to answer them with any substance and confidence.
Which is why I find this framing very helpful for building those product-reflexes — perfect for new/junior/inexperienced Product Managers and when it comes to more mature Product Managers I often still use it but rather I extend it to the product team — nothing better than getting everyone in the team thinking in these three buckets — after all, product dev is a team sport, it shouldn’t all rest on the Product Managers shoulders.
Think, Past. Present. Future.
