At OpenSpace, I quickly realized we needed a better way to scale our decision making and ensure that teams and product managers were empowered to make the best decisions without getting slowed down by questions or unnecessary meetings or buy-in.
The main problem was that many of the decisions had long been centralized with a few executives and leaders. As the company grew, and as the product and engineering team grew, I saw that we needed a way to ensure that we could move fast without sacrificing on core principles that we all agreed on.
But the key would be to agree on those key principles. First, as a product organization. Then as leadership and a broader company. So I led our team through several exercises (see the full presentation here) to determine where we were currently with our decisions, what we valued based on what we did, and where our most urgent problems were.
Once we identified the problems and tensions, we had a discussion about where those problems most frequently manifested themselves.
This helped generate additional ideas from our group and got us thinking more about our product areas and the places where we would benefit most from guiding principles.
From there, I asked everyone to take some additional time to write out the tensions they experienced, add any that they may have missed, and put those all on sticky notes so we could begin to decide what our principles should look like.
Plotting Tensions and Voting
Once everyone had a chance to write down their ideas, we put them on the wall. We took some time to group similar ideas and ensure that we all understood the notes that had been posted.
Once we had our groups, we plotted opposite ideas on continuums. I wanted to force us to pick a side. For example, should our product be very simple and targeted to new users? Or should it be very advanced and created for those who are experienced. While it may be possible to have a product that can do both, it is very difficult. And when we're making product decisions, it is much better to have a clear idea for everyone, if we're going to keep our experience very simple or if we're going to be the advanced software for professionals.
With that in mind, we created about 16 continuums with the tensions we wrote down. From there, I asked everyone to vote on each continuum, placing a dot where they thought we should focus. If our product should lean all the way to one side or the other, or if they were more in the middle. This gave us a plot of how everyone felt about our product and the principles we were forming as you can see:
Creating Product Principles
Once we had used our dots to vote, I led the team in a discussion about each of the continuums. I asked if anyone who had voted on either of the extremes wanted to give their opinion, especially in those cases when there wasn't a consensus or there was an outlier. This allowed us to begin to shape the overall principles as we discussed the thinking behind each continuum and the voting of the team.
I then took each of these and crafted our product principles and tenets. We used these with leadership to begin to get their input and acceptance in order to begin implementing the ideas as well as putting them into practice and testing them out.
I continued to update these principles as we got additional feedback, experimented with them, and revisited them periodically as a team.
Product Principles and Tenets
Leave a Reply.
My personal musings on a variety of topics.