The fastest development process you’ve never heard of.
My favorite process for building a product (with a small team) is the “squeaky wheel.” It’s essentially no process at all, but might be the most effective process I’ve ever used.
Create a “squeaky wheel” process: #
Weekly Monday morning meetings
Discuss road mapped priorities, and what everyone will be working on for the week. Now is the opportunity to make changes to that plan.These meetings should include the dev team, but should have at least one person who can represent external interests and priorities, either through a prior meeting, or their own independent discussions.
A team that uses the product, and feels ownership over everything. Everyone on your team is responsible for the final user experience (from first sales-touch to cancelling an account), and should feel empowered to speak up when something seems off, no matter how small. This is where the squeaky wheel begins to shine.
Solicit constant feedback and bug reports, publicly.
Setup slack channels dedicated to this process, and create threads for each report.NO UNIFIED BUG LIST
Do not track bug reports and feedback as a team. Nobody will consult that list. Not the developers, and not the people reporting the bugs.Respond to them in the moment:
- I will fix this right now (only if this won’t delay your road-mapped deliverables).
- Is this higher priority than Feature XYZ that I’m working on?
- if not, we will add it to the “backlog” which is the metaphorical void of nothingness.
- This becomes a request to “Please squeaky wheel this if it’s still a problem” [tomorrow || next week || next month]
Caveat - while these should not be tracked as a team, personal workload lists are still a great tool.
The outcomes #
This shifts the responsibility from the developer to the stakeholder. The developer will continue to work on the thing that is most important, and the stakeholder is not left wondering “when will this get done? It’s in their backlog…are they working on it yet?”
The answer is no. They are not! #
They are working on the agreed upon highest priority. #
So here is where the magic comes in… the stakeholder has organically become the project manager for this feature, and in a couple days, or a week, they can squeak that wheel, and ask the developers if it’s something that can be fixed…again.
Developers will only want to hear the same request so many times, before losing whatever is left of their sanity, and deciding to address the issue.
They will find the time, and make it a priority, because even though it might not be a “business priority”, it has clearly become a user priority - and therefore, a business priority. #
The time saving here is that developers are always working on what’s important, and what users want. They are not working on low-priority asks, or managing lists, and priorities - that has fallen to everyone using the product, including the customers.
We have been doing this for nearly 2 years at Aiera, and it has been the fastest development cycle I have ever worked on. We often ship fixes, and / or new features / functionality, within hours of them being requested by customers or team members.
Being unchained from rigid process has enabled us to move, and react. #
The “squeaky wheel” helps stakeholders better understand the reality of when their feature will be delivered - immediately, or maybe the next time they ask, but if they care about the product, they will continue to ask.
It creates a shared, empowered sense of ownership, “this improved because of me, because I cared enough to ask, again, and again, until it got done - it wasn’t my job, it was all of our jobs.”
It creates unity through a feeling of “we are building a truly kick ass product, and we are doing that together“. We see everyone reporting these bugs, caring as much. No heroes here. Just a team who wants to create something of value together.
We recognize priorities change from week-to-week as the environment we work and live in changes with it. That’s why it’s better to re-align at the start of every week - confirm your team is working on what is still most important, and to not be bound to any process.
Most processes are bureaucratic systems founded on people’s insecurities. They need to have input and control - to get some form of credit through a number of mind numbing meetings and discussions.
Build a good team, and trust their abilities to do their job. Or, maybe get a new team. Less is more.
The squeaky wheel isn’t about creating your road map, it’s about making your product much better, much faster, while reducing process, and improving culture.