Leading the Creation of Product Principles and Tenets

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

1. We value simplicity over robustness, and we prioritize the experience of new and less tech-savvy users over power users. 
   
2. We are prescriptive. We aren’t afraid to take a stand for what we think is best for our product and our users, and are prescriptive in our solutions.
   
3. We value speed. We move fast to get products and features into beta versions and limited releases, but prefer to move confidently and take our time when moving these features to all our customers.
   
4. We are creating a holistic solution for our industry, our customers, and our potential customers. We prefer to have a single solution to many problems over many solutions to many problems.
   
5. We build so customers can do it themselves. We trust our customers and value the ability for our users to self-serve. We build our products so they won’t need our help. 
   
6. We prioritize the user of our product, their needs, and their experience over our own business needs and the purchaser of our products. 
   
7. We integrate broadly. We build in a way that works with other applications and products in our industry so our users can easily move between OpenSpace and other applications they need.
   
8. We prioritize for the highest value. We recognize that some customers and customer groups are more important than others, and we prioritize for higher value, though not any single (or small group of) customer(s)
   
9. We prioritize the long-term over the short-term and are proactive rather than reactive.
   
10. We validate our assumptions. We deliberately explore problems deeply in order to validate our ideas and rely on quantitative and qualitative data to make decisions