The value of Product Principles

What are Product Principles? Why are they important? How to establish them? …and an example from GRID

Hjalmar Gislason
GRID

--

I realized the value of Product Principles when working on my previous startup — DataMarket. As a group we found that we would often have lengthy conversations on things such as how to approach a certain design or implementation, what to prioritize and when to compromise. We also found that in the end we’d often come to a conclusion based on the same set of relatively few arguments. Why not identify those, discuss them thoroughly and formalize? So we did, and the DataMarket Product Principles were born.

These guided our work for years, and often referred to. I also believe that divergence from these principles is a part of what caused the team to lose interest and ambition for the project after the acquisition, but that’s a story for another day!

When we — partly the same group — set out to build GRID, we came to the table with a somewhat common understanding of what we valued and what we felt was important, but about a year in, the team had grown to ~15 people and we decided to bring everyone together to discuss and formalize our own set of principles. These are now prominently displayed in our office, walking through them is an important part of new employee onboarding and referring to them is a part of everyday work at GRID:

GRID’s product principles on display in the main corridor in the office

What are Product Principles?

Product Principles are a set of arguments that you as a team want your product to manifest. As a result they will guide the way you work, the way you prioritize, when you compromise vs. where you go the extra mile, and help choose between different ways to approach a given issue. The principles may be aspirational insomuch as your product may not fully live up to them yet, but you want to know that you’re working towards the aspiration, not moving in the opposite direction.

Also, they are principles — not rules. They will and should sometimes be “broken”, but when that happens it should be done with care and deliberation. At times the principles will even be at odds with each other when it comes to certain decisions, which is an excellent reason to carefully discuss the matter at hand and come to a thoughtful conclusion.

Finally: Product principles are not set in stone, they are a living artifact that should evolve and mature with the company and its product.

Why Product Principles?

A good set of Product Principles that becomes an integral part of the organization’s work will:

  • Improve and speed up decision making
  • Ensure consistency in the product experience
  • Help resolve hotly debated issues
  • Make the team more confident in their work
  • Result in a better product

How to establish Product Principles?

There is no one right way to do this, but I’ll explain the process we went through.

Firstly: Product principles need to be something the team owns together. They can not “come from above”, so an inclusive process in setting and then regularily revisiting the principles is key.

In our case, I acted as a facilitator of the process and the principles’ “editor”.

  1. We began the process with a “post-it exercise” at an offsite. Everyone wrote down sentences that they “want to be true for our product”, and then read them aloud as they were posted on the wall, immediately grouping things that were the same or obviously related. A second round of grouping, labeling and organizing identified 5–6 major themes with some ~150 post-its in total.
  2. I wrote these themes and their corresponding post-its up, prioritizing, merging and cleaning them up as I saw best fit based on the conversations at the offsite. This resulted in a set of 6 themes with probably about 10 items each.
  3. A smaller group (established at the offsite) now came together to further discuss, organize and prioritize. Often we found ways to better articulate some of the items — or to come up with an “umbrella” that covered what had previously been 2–3 different ones. We also found ways to merge some of the themes, ending up with a set of 4 themes.
  4. Me again, this time trying to boil it down to only a few succinctly worded bullets for each theme without loosing the essence, resulting in a “full draft” of 4 sets of principles with 5–6 bullets each.
  5. The draft was now circulated to the entire team again for feedback for about a week.
  6. The smaller team came together again to consolidate the feedback, finalize the wording and put the stamp of approval on the principles. The result was a set of 4 approved themes with 3–4 bullet items each.

The most interesting outcome of this final meeting was that we concluded that Privacy needed to be broken out as a theme of its own. It had come through as something the team felt strongly about, but needed more articulation and a deeper conversation, so we ended up running a mini version of the process again resulting in a 5th theme. (details below)

A designer now got to play with this and the result are the 5 posters in the photo above.

In conclusion I’ll articulate each poster a bit to give you a sense for the result of this process, how we think about our product and work and give you an example that you may be able to emulate if you’re interested in establishing your own.

GRID’s Product Principles

Empower and Delight

This is core to our mission. A reminder to ourselves to keep the user experience front, right and center and think about it from the perspective of the everyday knowledge worker.

The word “ordinary” is a bit of a thorn there (nobody wants to be called “ordinary”, and in many ways nobody — or everybody? — is), but the cadence and flow of that sentence is just so nice. :)

Oh, and instant feedback is a big thing for us. For authors to be able to instantly see the results of their actions is key. If you have any doubts, watch Brett Victor’s Inventing on Principle. You’ll never think of products the same way again…

Meet people where they are

People may be looking for ways to improve their work, but the more you can fit into their existing ways of working, the more likely you are at succeeding.

GRID is built for spreadsheet users so it is natural to focus on them first. We go to lengths to make shortcut keys, conventions, formula syntax, ordering of data on charts, etc. follow what people are used to in their favorite spreadsheet software, and while GRID is built for both Excel and Google Sheets, where they differ we will usually go with Excel as a bigger part of our target audience uses Microsofts’ suite.

Our text editing and layouting takes patterns from both word processing software and modern web editors, with where it differs leans on the latter as our primary delivery is on the web and rarely intended for paged layout.

And finally: Whether you are consuming on a desktop or mobile, presenting in a board room or Zoom or printing your document for permanent storing, we think about all modes of consumption. GRID documents should just “feel right” whatever the setting is.

Facts over opinions

This one is more introspective than the previous two. It’s a reminder to ourselves that we are not typical users of our product, and even though we’ve studied the space and the user base thoroughly, we don’t instinctively know all the answers. Based on this we are rather meticulous about event tracking and measurements to understand where our users get into trouble, what are some of the most common drop-off points in the user experience, how much different features are used etc.

We also run “research spikes” ahead of major development efforts where we use a mix of qualitative and quantitative measures to better understand the users, their needs and the design and development efforts ahead.

Intuition still has it’s place in the process, but in the words of Jim Barksdale:

“If we have data, let’s look at data. If all we have are opinions, let’s go with mine”

Trust is earned

It can be easy to forget that there are people behind the numbers. Let’s not! What we provide our users and customers with is not just the technical product, but an entire service experience. So let’s make sure to make all interactions count. Trust is earned over time, but can be lost in an instance. Someone losing their work because of a bug in autosave should cause us at least as much angst and frustration as the user in question.

Admit mistakes, be transparent, act responsibly. It’s the adult thing to do.

We take privacy seriously

As explained above, throughout the process we realized we needed to break this one out specifically. Both because the team felt strongly about the issue, but also because this is one area where there can be conflicting views based on where you sit in the organization. Generally, growth efforts benefit from more tracking of personally identifiable information and being lax on privacy, while technically minded people often want to err on the side of caution in this regard. The conversation actually revealed that there wasn’t as much of a difference of opinion as one might have expected and we rather easily found ways to meet everyone’s goals.

Another reason people may treat this lightly is that there’s frankly a lot of work involved in understanding all the different laws and regulations, how they differ between regions and implementing everything in a compliant manner.

We put significant effort into our privacy implementation ahead of the launch earlier this year, and I believe we can be proud of where it’s at.

In conclusion

As you may have gathered from reading the above, Product Principles are near and dear to my heart. I strongly believe that a part of building a strong product offering is to have a set of good Product Principles that become an integral part of the team’s everyday work.

I hope the above can be an inspiration to others and I’d love to hear what you think. Feel free to comment below or Tweet at me @hjalli.

Hjalmar Gislason is the founder and CEO of GRID — the new face of spreadsheets.

--

--

Editor for

Founder and CEO of GRID (@grid_hq) — the future of numbers. Proud data nerd. Curious about everything. Founder of 5 software companies.