April 6, 2017
Chaos does not work well when trying to hit a deadline for new product features. Having a predictable product road map is one main key to success.
Going back to the point in my previous post about getting everyone on the same page, we started to see the need on our team for core members to get in room and "fight" for their ideas. Viewing those ideas in the context of the company as whole and not just the personal lens of what we feel is important is a crucial step in our process
Webconnex started a monthly "summit" meeting with key people in the company. Giving us a chance to bring all the ideas to the table and figuring out what is truly important for us as a company. Also finding out: what ideas matched our goals, what areas need re-evaluating, and most importantly gaining a unified approach. It is human nature to have a stronger bias to our individual ideas, but when you see your ideas on a ten foot white board next to everyone else's ideas, it quickly becomes a conversation about what is really the best for the company.
We are still pretty new with this practice and it really is a practice in every sense of the word. Old habits are hard to break, but it is giving us a foundation of communication and teamwork. The strength will ultimately make a better product and stronger company.
So why every month? Well, we are finding the month to be optimal for us for several reasons:
We find that four weeks allows for optimal time to get some solid work in, check the work for quality assurance and allow for inevitable evolutions to the features that happens when you sit with it for a while.
What you might have fought hard for the month before may seem like a non-issue the next month. This allows you to be less biased on individual ideas and opens the door to see how other team members ideas are more worth fighting for.
Estimating for resources is a challenge. The feature your team thinks is going to be easy, ends up taking five times as long. Also that huge feature you planned on using a ton of resources on ends up happening in a flash of brilliance. We keep logs of our engineering and design teams efforts in terms of work capacity by estimating everything from small bugs to large features with story points. Not a new concept at all, but what this does produce is an overall idea of our capacity for work. Knowing this rough estimate of capacity allows you to go into the "summit" meeting with a resource budget. Through assigning rough estimates of the number of story points to the features you can quickly get a picture of the overall work needed to do all the ideas and how many "points" you are over budget.
Naturally our biggest strengths can also be our biggest weaknesses. We needed to put more structure around planning our roadmap, but didn't want to lose one of our core strengths, flexibility. The month long schedule still enables us to react to changes in the market in a timely manner while still being able to have some predictability for the product as a whole.
Some features are fast to implement and some are slow. Knowing your capacity for work and talking about what is important helps you decide on how much you can get done in a month. The speed of a features implementation should never be the driving force in deciding if a feature should be implemented. The deciding factor should always hinge on your team's plan for the product as a whole. Some cycles you may have a whole freeway of Ferraris and some may have only a couple busses and that is totally fine.
We have all been there. You are on a road trip and inevitably someone needs to take a bathroom break. What is the most important thing that needs to happen here? EVERYONE NEEDS TO TAKE A BATHROOM BREAK. That last thing any well-versed road tripper wants to have happen is to have to stop in twenty more miles to allow someone else to visit the restroom only because they "didn't have to go" twenty miles back.
Ok. So what is the point of that analogy. Well. Take breaks. Look back on the road you have journeyed. The cars you have driven. What cars are still performing, which ones were total lemons? A failed feature should never be seen as a failure. It ultimately gave you insight into your customers, your team and your product. Failed features are incredible tools to create focus and make a better product. Talk about these failures with the team. Give people time to talk freely about what made a feature a success or a failure. If you do that, you will have the best team of product managers ever and more ideas will bring better features.
Disclaimer: This is a fluid and a constantly changing process for us. There are no silver bullets here. Your team's personality and culture is going to be different than ours. Your customer base and product is going to be different and to be honest we are constantly find ways to make smarter and more deliberate decisions about what our product is and what it should be.