Adventures in Product Design

The work of Bob Ricca


North Star: Revisiting Guiding Principles In Product Design

Product Design

Photo by Bogomil Mihaylov on Unsplash

Recently I came across a document I created years ago. From a retrospective point of view, I thought it was worth sharing.

• • •

The Year is 2014

I just accepted my first remote role working at ThreatQuotient. It was an exciting time for the company. Ryan and Wayne, the two founders, had received seed funding and were finally able to build a team.

At that point it was five of us:

  • Wayne and Ryan (the company founders)
  • Two talented full stack developers
  • A sales guy
  • … and me (doing anything design related)

Working at ThreatQuotient was a significant opportunity in my eyes. It was my chance to influence the direction of a product in its early stages. In hopes of learning from the advice of others, in my spare time I was absorbing anything I could about UX and product design. I wanted (and still want) ThreatQuotient to be successful. Although not everything is in my control, I still to this day correlate my professional value with the ability to have a positive impact on the company.

Within my first few weeks of employment, I created a Product/UX space in Confluence. Inspired by one of my personal heroes (Des Traynor @ Intercom), I started by outlining and rallying behind a list of principles I hoped would guide me to making smart product decisions.

The content below is in no way my own, but, it is timeless and valuable advice.

Product Guiding Principles

When analyzing a feature within the ecosystem of a product, ask the following:

  • Does this feature fit the end vision of the company?
  • Is the reward of using this feature greater than the effort we’re asking our users to make?
  • Does this benefit all of our customers?
  • Will it grow our business?
  • Will this feature matter in 5 years? (or are we just building today’s trend)
  • Is this a forward step for us? (or is this leveraging yesterday’s technology)
  • Will it generate new engagement?
  • If it succeeds, can we support it?

These reasons alone do not justify shipping a feature:

  • We’ve talked about this feature forever
  • We’ve worked on this feature for so long
  • We can do this pretty quickly
  • Generating value for customers is the end goal.

When assessing the value a feature provides for customers, consider the following:

  • A feature needs to be a solution to a real problem that exists today
  • It needs to be easy to build, test and refine
  • It needs to be easy to explain to a business
  • It needs to be easy to adopt by companies of all sizes

When looking at existing features, ask the following questions:

  • How many customers are currently using this feature?
  • How often do they use it?

All things on the product roadmap should fall under one of these categories:

  • Improving a feature
  • Getting more people to use a feature
  • Getting people to use a feature more
  • This is a new feature to support a new workflow

• • •

Four Years Later

Yesterday, I rediscovered this document.

It makes me think about how the market has evolved and all of the product decisions we’ve made over the last four years. I think about the customers we’ve had and how they have influenced our roadmap. I think of the new faces on the team and how we’ve evolved our processes.

This post is a personal reminder to revisit these principles.

It doesn’t have to be every day, or every week. But every so often it’ll do me good to revisit these basic principles and challenge why I’m doing what I’m doing.