Our recommended product stack
Unsure what tools to use to get your team up and running? Had enough of shoehorning your ways of working into that ham-fisted ticket management system? Here’s my tried and tested starter-for-ten product stack, with a few alternative options sprinkled in for good measure.
The heartbeat of a healthy product team, particularly in an increasingly remote-first world.
⭐️ Winner: Slack
It’s the easiest of the lot to use and tends to be the de facto in our line of work, especially for relatively new organisations. The fact it’s “comms in the open” by default unlike some others ensures you start on the front foot.
Regardless of what tooling you end up with here though, it’s important to try and set your stall out early. Write out your Slack etiquette (or borrow someone else’s, such as Slack's). Set up a community of practice. Call others out who don’t toe the line - “radical transparency” being the order of the day. Inconsistency and ill-discipline are the enemies of successful async comms.
I’ll just say it: Teams isn’t all that bad. More traditional and established organisations are often wedded to Microsoft and as a result will favour Teams over Slack. If you work with many different organisations, you’ll spend a lot of time there. Embrace it. Make it as good as you can. Leave it better than when you joined.
A blast from the past, but email does still have a place. Some organisations just don’t get instant messaging. Even organisations that have gone full Slack still have their fair share of old guard who are more responsive to emails than they are instant messages, or those people (we all know them) who send emails for higher-stakes matters. I’m afraid email isn’t going anywhere anytime soon. Try and check ‘em at least once a day!
Being able to jump on a call with people anywhere on any tech in any organisation is integral.
⭐️ Winner: Google Meet
There isn’t much between the video calling big players. What swings it for Google is its lightweight onboarding, ubiquity, reliability, and simpler user experience.
A year or two ago Slack wouldn’t have made the list but it seems to have come on a lot in that time. In practice, any of these will do the job, and often the best one to use is the one that has the best coverage across your organisation or regular invitees.
Once you’ve got your video calling and async comms sorted, the magic really begins to happen once you fully embrace a collaboration tool. It’s the secret sauce. The bit that you didn’t know was missing. You go from endlessly talking in circles to being laser focused. The canvas you all hack away at during a call becomes your meeting minutes. Your documentation. No longer does knowledge dribble down the drain the moment you move on to the next call.
⭐️ Winner: Miro
I was introduced to Miro in March 2020 the week after the first COVID lockdown in the UK, whilst working on a 12-week discovery for a global consultancy. It was incredible to see the speed and enthusiasm with which it was adopted. All of a sudden we were able to run ideation sessions with practitioners from not only anywhere in the UK, but we also had experts join us from San Francisco, Eastern Europe, and Scandinavia, whilst the client’s less-than-tech-savvy front-line workers all managed to join us on our Miro board with little or no problem.
It was game-changing.
Honourable mention: In real life
If you can, then do! Everyone is different (obvs), but I've settled on meeting up in person for work around two to four times a month, and wouldn’t be without it. This seems a common cadence from conversations I've had with others across the industry.
Two tips here:
- Don’t make anyone joining remotely feel like a second-class citizen if at all possible.
- Try and use the time to do something different. Meeting up for retro and sprint planning probably won’t be the draw that you want it to be. Go out for lunch. Do something exciting.
Visualising work in progress
Your kanban board is like the village notice board. The campfire. The place you automatically gather around. It brings focus to ceremonies and conversations, keeps you honest, and highlights issues and blockers early.
⭐️ Winner: Jira
Not without its limitations and quirks, but still our go-to. Especially now you can get up and running with their simplified next-gen setup in minutes. I still see people join new organisations and be taken aback to find that they don’t use Jira.
If your wiki is in Confluence, then that only adds weight to the recommendation.
They’ll all do a job, and all have their advantages - the simplicity of Trello, layering Zenhub on top of GitHub to avoid Atlassian altogether, Azure Boards' ease of integration if you happen to be a .NET house.
Honourable mention: Miro
A decent “ticketing system” might get you through the day-to-day, particularly on the delivery side, but it’s often too granular and frankly too messy to hang higher-level conversations off. That’s where Miro can come in. Yes, it’s throw-away, but creating a simple view of the salient work items using boxes on a Miro canvas can make everything that little bit simpler if, for example, you’re just looking to talk about the core deliverables of your next big-ticket item. It immediately cuts through all of the noise that you would see on Jira's kanban view or even the roadmap view.
⭐️ Winner: Miro
I would have said confluence pre-pandemic - perhaps even six or 12 months ago - but since beginning almost afresh with Miro at a couple of places, it’s definitely the place I would recommend starting. All of your key artefacts can easily be created in Miro, and it’s so much easier, engaging, and collaborative to have them nice and visual and in your face, than tucked away in some dusty old wiki.
Miro love-in aside, wikis and more structured artefacts do have their place. It isn’t long before a Miro board begins to creak, and it isn’t the place for bulky documentation. Findability and readability quickly degrades and that’s where the likes of Confluence and Google Drive come in. It’s not uncommon for Miro to hand off to other knowledge management systems.
One of the first things you’re likely to introduce new starters to, and make-or-break both in terms of team engagement and whether your product actually makes an impact.
⭐️ Winner: Miro
Simplicity and flexibility are important when describing your team’s motivations and tracking progress towards goals. The visibility and accessibility afforded by Miro win the day here. See our Product Team Canvas Miro Template for ideas.
If your team is long-lived, or your goals are plentiful and/or regularly refreshed, the longevity and volume makes a case for keeping it in a wiki.
Sometimes an after-thought, or at best a poor relation, having an up-to-date and well-managed diary can make a big difference.
⭐️ Winner: Google Workspace
Its clean and crisp UI, and integration with other Google tooling gives Workspace the nod here.
And it’s cheaper.
But the key here is - for want of a better word - hygiene. A “calendar cheat sheet” never hurts. How do you let the rest of the team know when you’re off? Do you have a shared distribution list that you can use to invite the whole team in one bang?
There’ll probably be no avoiding it. Most of my working life has involved having both Google and Outlook calendars open at the same time.
Honourable mention: Calendly
Wrangling people to unearth mutual availability is a real pain. At least for one-to-one sessions, the simple and transactional nature has really helped me to engage more of late.
It takes discipline to keep it up-to-date (if anyone knows a way to sync up two calendars with Calendly please let me know!), but the frictionless experience for the recipient definitely helps to get things moving.
Any product team worth its salt will have a dashboard powered by one or more analytics tools. It’ll help them track key performance indicators. It’ll be one of the key artefacts they talk through with newbies. It’ll be one of their most effective sources of user insight.
⭐️ Winner: Adobe Analytics
Formerly a Google Analytics fanboy, we’ve drifted apart as I’ve advanced through my thirties. Two run-ins with Adobe Analytics swung it for me, where I saw it having a real impact. While Google Analytics has a flatter learning curve, and on the surface looks a lot slicker, the more I saw it used, the more it seemed to be an after-thought and proved difficult to extract meaningful insights from.
Going one further than product analytics, a lot of the good stuff can come from deeper down in your stack. Where product analytics might be your go-to for how many monthly users you have or how users interact with your product, data analysis can give you a richer snapshot of the current state of the world, as well as historical trends. How many accounts do you have in each market? How long does your onboarding process take? Which of your vendors takes the longest to deliver their products? The gnarly questions where in-app analytics just won’t cut it.
The best setup I have seen throughout my career was where an event-driven architecture pushed all data into a Snowflake data lake, where it was transformed and combined with other data sources. Product teams could then use the data visualisation tooling layered on top (Metabase in this case) to get the insights they need, or where this didn’t cut it could go straight to Snowflake to query the data directly.
The only criticism here was that we soon hit the limits of what Metabase could do, hence recommending Tableau which I’ve seen used to great effect at various places.
As mentioned above, whilst Metabase is great to get you started, it is not without its limitations. And PowerBI doesn’t play nicely with Mac, which tends to rule it out.
Don’t be afraid of rolling your sleeves up and manipulating data in spreadsheets when the situation calls for it.
I’ve joined teams who have just accepted that they can’t get answers to burning questions until their data engineering and analysis colleagues unblock them, but when you pull at the thread you’ll find the answers are there - it just needs someone in the product team to spend an hour handballing data. Perfect is only the enemy of good if you let it be.
You can have the best user researcher in the world, unlimited access to perfect candidates, and all the time and organisational support in the world, but if your tooling isn’t on point then you’ll never get the most out of it.
I’ve split user research into four broad categories:
- One-on-one in-person research
- One-on-one remote research
- Research en masse
- In-product research
One-on-one in-person research
This all depends on the type of research, your objectives, the devices involved, and how involved you would like your team to be.
With in-person research, it's always preferable for participants to bring their own device. Therefore, setting up some cameras and using a free tool like OBS which allows you to capture numerous input devices at the same time, is a great way of recording the session with minimal setup time.
If the research involves testing prototypes, then Framer is currently our preferred choice. Framer's ability to create both design and React code components enables you to create highly interactive, realistic prototypes, that other tools simply don't.
If you are looking to engage team members, a good way to do so can be to dial them in via Google Meet and screen share from the device that will record the user and/or the research activity. The team can then record insights centrally - ideally on a pre-prepared and shared Miro board - to help the researcher consolidate and analyse findings. The advantage of others observing remotely is, as well as them being able to join from anywhere, there is no risk of them intimidating or overwhelming the participant by all huddling around the same desk.
- Recording: Usertesting.com, Lookback
- Prototyping: Figma, inVision
- Remote observation: Microsoft Teams
One-on-one remote research
A similar stack as for in-person research, but using Lookback as a means of facilitating the research session as well as recording it, with more of an emphasis on Miro where it can help bring structure to more exploratory sessions.
The most fruitful remote research I’ve seen has typically involved interviews recorded on Lookback, talking around a prototype, a product (web or mobile app usually), or some centralised content on a Miro board.
Much like in-person, you can dial other members into the call using Google Meet or similar, and have them record notes on a Miro board.
- Recording: Usertesting.com, device screen capture, video call recording
- Prototyping: Figma, inVision
- Remote observation: Microsoft Teams
Honourable mention: Usertesting.com unmoderated research
I’ve seen mixed results from this approach, but it can glean some insights and is incredibly simple to set up and adjust. Just be sure to take learnings with a healthy dose of scepticism as a lot of the candidates are effectively professionals, serving up an opinion just for the sake of it.
Research en masse
On the quantitative side, surveys are the vehicle of choice, providing you with sufficient data to enable decision-making.
⭐️ Winner: Google Forms
Versatile enough to enable you to structure surveys to capture the data you need, and the user interface is familiar enough to not trip too many users up.
Getting feedback from real users whilst they use your product can also be a great source of insight, although you have to be disciplined to only use it sparingly so as to not negatively impact users’ experiences.
It’s worth noting that this section is only really relevant for web-based products as opposed to mobile apps, although I’m sure equivalent tooling exists out there for iOS and Android.
⭐️ Winner: Hotjar
Really easy to implement and configure, it’s a simple way to enable you to begin recording active sessions on your product, capturing user feedback on the go, and dropping in targeted surveys directly to users.
Probably more to help unpick performance issues and defects, but Datadog does have a similar screen recording capability that can help you better understand how users interact with your product.
In the climate of you build it you run it, being able to see how your product is performing in real-time and being actively kicked when potential issues are brewing is hugely important.
The best teams I’ve worked with share the load when it comes to observability (or o11y, to give it its shorthand). It doesn’t just fall on a single automation engineer or the engineers as a collective - it is the shared responsibility of the whole team. You all keep an eye on the o11y dashboard. You look at it in stand-ups. It’s not uncommon for multiple people to pounce on an alert in your Slack channel within minutes.
⭐️ Winner: Datadog
The list above is shaped almost exclusively by my personal experience. I’ve tried to temper it by running it by a handful of ever-reliable industry sounding boards, but it is worth noting I’ve never worked with this exact stack.
If you’re kicking off a new operation, or don’t have a lot of the above in place, don’t feel like you have to go from zero to a hundred all at once - you absolutely don’t (and in all likelihood couldn’t even if you tried).
Each organisation has its own preferences, constraints, skill sets, and commercial arrangements, so it’s just as important to be well-versed in a few alternatives and prepared to adapt and embrace them. Don’t be that guy who blasts a certain tool every chance they get because it doesn’t happen to be their favourite. Make the most of it.