We have a big vision at ThoughtSpot: To be the simplest, yet most powerful data insights platform for everyone. Bringing this vision to life presents a few challenges: Design data experiences that have never been conceived or built, target and engage a new audience, and create and grow a new category. We had our work cut out for us.
Building this vision requires a big team. Like many companies, our product team, which comprises design, pm, and engineering, is distributed across different offices internationally. It’s important that our vision is deeply internalized by everyone on the team, so it informs the hundreds of product decisions that get made every week. To codify our vision, we decided to develop a set of product principles—idea-driven guidelines to inform key strategic decisions and help break any stalemates.
These rules are similar to the design principles commonly used at companies like Google and Facebook, but they go one step further. They’re written to be used, not just by designers, but by anyone who touches the product experience: Engineers, Product Managers, Technical Writers, Customer Success, and Product Marketing.
Thanks to our success so far, we’ve been asked about our process for developing these product principles. Here’s a revealing look at how we did it.
Defining the audience
At ThoughtSpot, we identified particular internal teams as key to creating and building products: marketing, design, product management, growth, engineering and customer success. Though their skills and talents were very different, it was important from the outset that they bought into a single vision.
Sharing that vision among so many levels of functionality can be tricky even when teams are small, but on top of everything else, we planned to scale up rapidly. We knew there could be trouble ahead if we didn’t proactively get everyone on the same page.
That’s where product principles came in. By referring to them every time key decisions came up, our teams were able to sing from the same songbook and fulfill our vision: making data insights fast, smart, easy and engaging for everyone.
Principles for the principles
To inspire so many diverse teams, and also serve as the “glue” between teams, we created a list of quality goals that our principles had to meet: They needed to be memorable, specific, directional, comprehensive, and perhaps most importantly, inspirational.
Memorable: We needed a quick checklist for key decisions, so principles had to stay short and “sticky.”
Specific: To avoid any ambiguity, we used vocabulary and concepts from our own industry, business intelligence.
Directional: We wanted our principles to promote decision-making and actionability. At the end of the day, that’s why they exist.
Comprehensive: We needed to include the appropriate amount of detail. But it didn’t matter if some principles contradicted others—that’s actually a good thing. What we were looking for was balance.
Inspirational: The principles needed to embody the vision that launched ThoughtSpot, and capture the ideas that brought it to life.
By the way, the number of principles is important too. Three aren’t much use; nine is too many, five is a great number, if you can get there. For us, it’s important to be comprehensive and have principles that work for the entire team. We landed on seven. We might refine these to five or six over time.
Then, we set up a brainstorm. Using the five rules of thumb above, we gathered representatives from all the relevant teams in a comfortable room with a whiteboard and a good lunch.
We started by writing down everything we might say to inspire our teams. What should they do? What should they remember? How could they best build something great? Especially, we noted non-negotiable attributes like speed or reliability. We also zeroed in on any tenets that surfaced repeatedly during product discussions. Finally, we were honest enough to acknowledge any tradeoffs in the existing product.
Then, we used all of this input to brainstorm potential product principles. At this stage, we were looking for raw quantity, not quality. Then, when we had a good pile to work with, we grouped similar principles into categories, stack-ranking them within each category from most to least important.
When we were all done, we had our best writer draft up the principles that got voted to the top of each category. Then, we got feedback, first from the brainstorming team itself, then from a handful of team leads and the broader organization. We had our writer incorporate that feedback, then circulated the principles again. Finally, we tested them, injecting them into product design conversations and observing how they hold up.
Even the best principles are for naught if no one actually uses them, so you’ll want to put some effort into keeping them top-of-mind. We created a slide deck, but you could also use a short snappy Word document, posters that pop in the hallways, or even a mini-book. Finally, we conducted interactive workshops at our different offices. We asked teams to brainstorm and discuss how they might apply the principles to their projects and what they’ll do differently. And we learned as much as they did.
We hope your new product principles help you as much as ours helped us at ThoughtSpot. Good luck!