How to Build Fast Part 2: Product Managers
This article is the second in a series on How to Build Fast — read part one on team culture here.
Building a product fast is hard. But what about building a delightful, intuitive, functional, and ethical product fast? Well, if it were easy, we’d all be doing it no problem. The truth is that many key factors must align in order to very quickly build a good product, and for PMs, like myself, a big part of our role is helping drive this alignment. I’m here to talk about the tactics I’ve used on projects where the old cliche is oh-so true: so much to do, so little time.
1. Stay in tune with your user’s needs
The best products are those that are built with the user’s needs top of mind. Aarron Waltern’s Hierarchy of User Needs riffs on Maslow’s hierarchy of human needs — it defines the basic user needs that a product must fulfill before more advanced needs can be met.
At first glance, Waltern’s model might convey the idea that a product’s functionality must be completely established before moving on to building out the reliability, usability, and ultimately, the delightfulness in the user’s product experience. However, when we build fast, we generally don’t have the luxury of building each block of the pyramid in its entirety before moving up. When thinking about which features belong in our first iteration release (or MVP (minimum viable product)), we need to recognize that a great product isn’t purely functional, just as a great product isn’t purely delightful. The best product teams find a way to address each user need slice in the features they build by cutting across the pyramid, rather than working sequentially from bottom to top.
For example, you may build well rounded features that are functional, reliable, usable, and pleasurable, rather than building ten features that are simply functional without any UI polish or user testing done. This ensures that the initial release provides a holistic user experience, no matter how big or small the product offering is.
2. Demo often
Have you ever looked forward to a feature demo by your team, only to leave the meeting thinking “wait… what? That’s not what we said we were building.” This can happen despite a team’s best efforts to clearly lay out all the feature requirements, and it’s no one’s fault. In today’s primarily remote world, you might encounter these moments more often. It’s a natural repercussion of not sitting next to our team all day, and not having the option to walk three feet to someone else’s desk and get a quick visual rundown of their progress.
In shorter, faster projects, sprints are already crunched and it can be incredibly difficult to find the time to course correct a feature gone awry without throwing the entire schedule off balance. To avoid this, my strategy of choice is demos. Mandating a team wide demo each week (ours is on Friday mornings) as a baseline, with smaller ad-hoc demos as required (for example when a ticket is completed in your backlog, or you have strict deadlines coming up) helps keep your team on the same wavelength.
3. Keep yourself, your team, and your roadmap honest
A delivery roadmap can truly be a PM’s best friend. Laying out features in a roadmap helps drive prioritization and alignment with a team and ground the project in an asset that can be referenced day in and day out. On fast moving projects, it can be easy to lose sight of the bigger picture and get sucked into the grind of our many daily activities.
On my current project, we have begun using a team-wide roadmap review as a way to kick off iteration planning meetings (IPMs) every Monday morning, which acts as a reminder of the coming week’s priorities and provides a visual representation of how all our different tasks correlate over a span of weeks or months.
The other tricky thing about fast moving projects is that things are constantly changing, meaning our roadmap is constantly changing too. It’s critical to involve the engineers and designers on your team in the day-to-day evolution of this roadmap throughout the lifecycle of the project, making sure that the plan outlines mitigations for risk areas and accurately reflects the effort required to build out different pieces of the product. This works to keep you and your team honest as you work hard towards a solution, with the bonus of giving stakeholders and leadership a clear view into your world, showing them you have everything under control.
While I’ve outlined some strategies that have worked for myself and my teams, remember that as a PM there is no one set of rules that you must follow to successfully deliver a product fast. What matters isn’t the rules, what matters is the focus: build better products. With this in mind your team, your stakeholders, and your roadmap can work together to delight users at an accelerated rate. Short and fast projects require agility and buy-in from the whole team, so stay tuned for the next article in this series, which will provide you with tips on how to build fast from an engineer’s perspective.
