How to Create the Perfect Product Development Process
Tips and resources for crafting a stellar product development practice
The process that you follow dictates the pace and quality with which you and your team develops product. It consists of all of the meetings, rules, JIRA boards, standups, ceremonies, and other constructs that are put in place to ensure that projects are consistent in direction and pace. They come in many shapes and sizes — Lean, Scrum, Waterfall, XP, and Kanban — to name a few.
The perfect process can clear blockers, keep everyone focused, and help frame projects according to their place within a wider strategy.
Bad processes can distract teams from their work, restrict creativity with overly strict rules, and ultimately result in projects that aren’t successful.
With this in mind, the first thing to know about the Perfect product development process is
There is no perfect product development process
No single process is ever going to work for every project, team, or team-member. Perfect is irritatingly elusive, and the best you can do is better.
How, then, can we ensure that the processes we’re putting in place are working the way we think?
Listen to the experts…
If there’s something I’ve come to learn in my time managing product, it’s that I never really have a firm grasp on how little I truly know.
There are volumes of material out there on various product approaches, and it’s important to have some baseline knowledge on the essentials. I like to refer to the tools and techniques out there as tools in a product person’s toolbelt — the more you’ve built up your toolbelt, the more likely you are to have the tool for a particular challenge.
The Agile Manifesto offers a succinct look at the origins of “Agile” software development. Iterating, moving fast & breaking things, MVP — these are all artifacts of the Agile movement.
From there, you might go check out something like User Story Mapping, by Jeff Patton, which wonderfully expounds on some of the tools that a team might use to ensure that product discussions remain centered around the people using the product.
Sprint, by Jake Knapp (and the rest of the team at Google Ventures) is a great example of a process that a team can follow when they’re looking to find that first version of your product that will answer your big foundational questions around product/ market fit.
…and then know when to ignore them
Ultimately, there are a lot of great books out there that will tell you some great ways that product can happen. Ultimately, how product should happen isn’t something that you’re going to learn from a book. There isn’t a book out there that knows all of the nuances surrounding your team, your product, and your organization.
Let’s take Scrum as an example. It’s a fantastic methodology, I recommend The Elements of Scrum, by Chris Sims, but it involves a lot of ceremonies (fancy word for meetings). In practice, I find that most teams decide that “Textbook Scrum” isn’t for them, and they find a more pared down version that more suits their team’s style.
Success ultimately stems from understanding the principles of product development, and knowing when to deviate from them.
Experiment & Iterate
So you’ve decided to implement a particular product development methodology. How do you know it’s working? How do you know it’s working as well as it could work?
When we’re building software, we constantly espouse the ideas of iterating, observing, measuring, and repeating. These same principles apply to the processes that we craft to enable the creation of our software. If we hope to create the perfect process for our team, we need to experiment.
There are a lot of great ways that you can make little changes to your process that can result in changes. My teams and I have experimented with pair programming, eliminating ticket assignments, mini-sprints, and 100% sticky notes. Some worked, most didn’t, and that’s ok!
The one thing that I can say about every experiment I’ve made with my team is that they have helped to engage the team in a quality discourse about the merits of the process that we have in place at the time, which reminds me…
Talk to your team!
The retrospective is one of the most powerful, underutilized tools in the product person’s toolbelt. Use it!
In my limited time as a product manager, talking to my users has been the biggest determining factor in whether a product succeeds or fails. It seems obvious after the fact, but the more you know about a user, the fewer questions you have about how they’ll experience various parts of your product.
Just like your customers and users consume the User Experiences and products that your team creates, your team consumes the product development process that you’ve created, and if you don’t talk to them you’re never going to know for sure whether it’s being experienced positively or not.
Face it, your team is probably going to have better ideas about how a process that might work for them than you will.
Thanks for reading! I’m Jack Moore, and I love writing about product.
This story is published in The Startup, Medium’s largest entrepreneurship publication followed by 318,983+ people.
Subscribe to receive our top stories here.
