How remote teams can build up their Product Machine

Here's two problems that remote working brought about for us at TouchNote: it hindered visibility and accountability, and exposed gaps in process. Suddenly you were cut off from the invaluable micro-conversations taking place in the office, the whiteboarding sessions, the huddles. These interactions are the glue that holds the entire edifice together. And now this has been the definition of business not as usual.

I mused over this problem quite a bit. Here's how I viewed it: our 'product machine' takes a series of inputs, applies certain actions to them, moves them across people and departments, and produces outcomes. This is what process is, really. The second part of this is about illuminating every step, milestone and owner of the machine. This is what visibility and accountability means.

So I set out with the goal of fixing this. First, I observed the iterations of our current 'machine', to identify what fell through and when. For example I was getting feedback from other stakeholders, like Growth, that they were unsure in this new world how and where they'd add an initiative they need, and what the process was for it to be considered for development.

Then I got to the root cause of the issue, which was our inadequate documentation of how we do things, and the mishmash of tools we were using: backlog and roadmap in Google Sheets, tasks in Basecamp, release announcements on Slack, etc. So my team and I formulated a plan to get everyone aligned by unifying our tools, and documenting the important processes.

Here's what came out of it: we're using Monday.com, for starters, for everything. Very powerful, flexible and intuitive tool. We've added several automations (for, say, changing an initiative's status to 'next sprint', and its automatically moving from the backlog, which houses all initiatives, to the delivery board, which includes only the ones upcoming for dev), and we've added owners, delivery dates, consistent updates, and all that jazz.

In regards to the product machine, I implemented and documented the following: every initiative is born with a one-pager in the backlog, which helps other stakeholders understand what outcome you want to achieve, and why you support this initiative. Then as a Product team we Triage this and decide whether we need to do Discovery work (user testing, research etc) to understand it deeper. Afterwards we apply the ICE prioritisation framework - but at this point, only the IC part (Impact and Confidence). That's because the top ones are assigned a Product Manager and get a seat at the Tech Weekly table, so the developers can outline implementation and thus give an E (Ease) score.

After that, things flow downstream towards producing a full spec and allocating resources based on priority and capacity, which leads to an estimated delivery date and of course, delivery. Importantly, though, this doesn't end here: there's a crucial piece of analysis that needs to be done after a feature is shipped, whether it's an AB test, or not. Based on the KPIs we've defined in the one-pager, or perhaps refined in the course of the full spec, expectations are set, and need to be held against the actual results we're observing at the users' hands. This helps so you don't fall in the trap of the feature factory that ships and forgets: hold yourself and your team accountable to the outcomes you want to achieve, and keep at it until you move the right metrics to the right direction.

The result of all this: a standardised framework for feeding requirements into the backlog, a shared understanding of effort and value, and a clear idea of an initiative's status and delivery date. All in all - a happy team, satisfied stakeholders, and rapid execution. A clear, transparent and tailored product machine will be invaluable to take you there.

---

Read more about remote working and product management at Toptal.