Creating digital products is hard. Not hard like studying for a test. Hard like building a skyscraper. There is a fantastic plan that you believe in and then reality rudely intervenes. Plans change, new problems arise, demos are requested, funding is adjusted, timelines are shortened. And of course, it’s not enough make a feature work just for yourself. You have to consider the world: their devices, their browsers, their networks. Fortunately it doesn’t need to work all of the time, just 99.99999%. It’s no wonder we spend an enormous amount of time thinking about *how* to build digital products, how to approach problems and what process we should use. This isn’t what we should be focusing on.
We’ve worked on hundreds of projects and been exposed to thousands. We’ve seen all the processes, waterfall to agile to kanban. We’ve seen all the tools, from MS Project to Rational Rose to Jira to Trello to sticky notes. The funny thing is, we’ve seen them all succeed, and all fail. I’ll say it again for the people in the back, we’ve seen all of these approaches to creating software products used to dig enormous useless digital holes in the ground as well as unbelievable glimmering matrix style skyscrapers.
The same process question always comes up: What’s the best process for developing software products? The answer is simple, but not gratifying: there isn’t one. It turns out creating products from this complicated digital stuff is not about a single process or tool, it’s about discipline.
The most common success story we experience is this: small team, five people, built an exceptional product in a short period of time. A product that caught the imagination and worked, most of the time. There was always more work to do, but the team achieved critical mass. When you meet one of these teams, or better yet are on one of these teams, it’s easy to see what is happening. Singular team focus, lots of communication, more time creating than meeting, and an agreed upon approach to managing who does what when.
There is no silver bullet process across all of the small teams out there. However, there is a common approach on each team, and it could be anything, as long as it is consistent. Critically and quite naturally, on a small team, the chance of everyone consistently using the same approach is very high. When the team finds a process or tool that works, they will use it, there is generally no time to spare or split hairs. This is an implied discipline.
If there are no specific processes or tools that increase the chances of successfully developing a product, how do we scale to larger teams? This is where things get hard again, and where process and tools start to be important. However, it is not the process or tool that is important, it is that everyone on the team uses them, uses them the same way, and knows why they are using them. This is explicit discipline.
Across all of the projects we have seen, the most successful teams have an explicit discipline around their approach to developing their products. Never perfect, but adopted by everyone on the team. These are the hallmarks of working disciplines from the product development front:
Know your process… and why This may seem obvious, but can everyone on your team explain how the process works? If they can explain how, can they describe why it is valuable for the team? When folks on a team can articulate how and why, they can move independently with the knowledge that they will do the right thing for their team and project.
Understanding the why may feel a bit abstract but this is the most essential element in high functioning teams. Understanding why not only allows people to make better decisions, they can help improve the process. If every team member has a deep enough understanding of what is happening and why to have a critical eye, imagine the improvements that can be made as the team gains experience.
Know your tools It’s painful to see the glee on a developers face diving into a Jira ticket alongside the horror on a designers face as they try to extract what in the world they should actually be looking at in the Jira interface. Not to pick on Jira, they seem to be winning in the enterprise, but no one can blame the designer when one of the leading tools is a nightmare for many team members to use. Enough of the soapbox though, the point is that everyone on great teams know their tools whether it brings joy or not. Not everyone need be an expert, but everyone, including managers, must be able to use the tools the way the team intends.
Language Precise language rules the day. Great teams use the same terms for their tools, processes, product references, code patterns and just about anything else they have to discuss as part of developing their product. Have you ever sat through, or participated in, a conversation of deeply precise people debating, but usually arguing, about correct naming. Or worse yet, witnessed the one sided argument, where the other person silently disagrees. This makes communication hard. It makes scaling a team harder. There is no excuse for not having precise naming conventions and references. Although it takes time, and their are always new terms to sort out, but great teams have this wired.
Meetings Working teams use the time they need, not the time they have. Their meeting time is considered precious and used efficiently. This can cut both ways of course. Meeting done early? Let the team move on. Didn’t finish what was planned? Figure out how to conclude by extending time, finding another time, or using a different medium. Don’t leave the team in limbo. There are many great resources on how to run great meetings. Find a consistent way to run your meetings.
Double Loop Learning aka Retrospective One of the most powerful tools related to repeatable processes is the act of reflecting on how the process might be improved. We like to call these retrospectives. The academically inclined will know this as Double Loop Learning. The point is that disciplined teams are not blindly using tools and processes. They are considering why an approach is working or not working. Regardless of what this is called, the best teams are looking for ways to be better. It might be once a week or once a quarter, but there is a moment of reflection to identify ways to improve.
High octane product teams come in all shapes and sizes, and use all types of processes. It’s not enough to hope that your team will work well or pin your hopes on a particular process. The best teams go beyond an implied discipline, they drive discipline as part of their overall approach. These are the teams that consistently deliver. Discipline, far more than the chosen process, is what defines their success. If you find yourself wondering where your product development is getting tangled up, try skipping the obligatory process review, and take a look at process discipline across your entire team. You might find that the actual process is secondary.