We were going through this overall process to clarify and articulate the company’s stance around product vision and strategy. Setting product principles is one of the important parts of that in my view. Whereas the 

help articulate what we are going to do, the product principles articulate how we're going to do it. In particular, when we are faced with difficult trade-offs where it seems like there could be multiple viable paths forward, our stance and guiding principles stated here will help us make those decisions.

We came up with these together with the engineering leads, the product managers and the product designers - three or four of each of those those roles together in a room. We started with a FigJam board, established some shared context around what principles are, why they're useful, what we were trying to create, that we were going to have these two separate lists. Then we did a brainstorm of some of the unspoken principles that we think we already have, but we hadn't really articulated. 

We also brainstormed a set of challenges that we felt like we were facing or types of trade-offs that we struggled with on a regular basis that would be really helpful to have some principles to help guide us through in the future. From that, one of the product managers and I each took took a pass at trying to synthesize. We then made a recommended set of principles based on the conversation, shared it back with the the leads in that same group to get their feedback, who then did a couple of passes on it before we published this to the larger company.

Setting product principles doesn't work if one person just goes into a corner by themselves and pumps out what they think the principles should be, because the principles won't be referenced or adopted by the broader team if they’re not bought in and if those principles don't actually resonate with them. 

I would suggest starting by gathering input from the people who are going to most be affected. From there, the product manager or product designer should synthesize and tease out the main themes within their group. Then those recommendations can be brought to leadership and get more consideration with that buy-in already in place.

I learned to set to create separate products principles for product development and product design from 

. That really resonated with me not because development and design shouldn't or don't work well together, but because there are there are like enough discreet, meaningful principles in each of those areas that it made sense to me to have separate lists. That way we could capture everything that was going to be meaningful and necessary to help guide us in our product development process. 

The product development principles are actually for the entire product development team, which includes product managers and product designers. That column is about how we approach building product together, whereas with the product design principles, we also saw a need to articulate a product design philosophy for the guiding principles of how our user experience should behave, what it should be like, which is an ‘apples and oranges’ to the how we work together.

Vicky Thomas

A set of product principles for product development and design at Clockwise. I built this with input from our product development team and product design team to help inform and use as a reference point for our various projects.

Product Principles are statements that provide guidance about the experiences we create, and how we work together to create them. They’re especially useful in helping us know which path to take when making difficult trade-offs. They don’t need to be comprehensive, but they should provide opinionated guidance on issues we frequently grapple with. At their best, product principles establish shared vernacular, and are frequently referenced by individuals and teams across EPD in their day-to-day work. 

Great product teams revisit and evolve their principles over time.

For more information and examples of Product Principles, check out this 

Time is our most valuable resource. We put just the right amount of effort into framing, designing, or developing a feature as its estimated impact. We don’t spend more time on something than it’s worth.

We get out of our own heads and into our users’, knowing that they are the 

 experts in our product. We regularly talk to them to understand their needs, and consistently gut check if what we’re building solves their 

We define a fully-featured vision so we have the bigger picture in mind, but we don’t let that slow our delivery of near-term value.

We favor detailed definition over abstract concepts, knowing that internal ideas and storytelling mean nothing until we ship real product.

We race to get our work in front of real users, and we break down delivery so we can start small. Rapid learning is the name of the game, and prototypes are worth 100 meetings.

We ensure our product launches ladder up to cohesive strategic progress. Project success metrics are important, but can be misleading. 

 success comes from delivering user value, as described in our product vision, in a way that drives meaningful business outcomes.

It’s our job to build end-to-end, educating users and thoughtfully considering entry & exit points in our definition of done.

Clockwise is Simple, Delightful, and Opinionated but Flexible

Be simple and straightforward in visual design and in copy. Show, don’t tell.

Design for short attention spans: prefer being simple over being comprehensive.

Beware the point of (rapidly) diminishing returns! It’s easy to overthink, over-design, and over-engineer, especially in pursuit of a product that is, and feels, intelligent. With that said, people will never 

 rely on Clockwise for automatic calendar management if it fails to consider important details.

When we identify non-negotiable nuance, we must design elegant, sustainable solutions. Hard-coded assumptions about edge cases will not get us where we need to go.

In a world with many competing calendar management alternatives, a great experience isn’t a nice-to-have - it is 

 strategy. We’re betting on empathy, as expressed through UI that recognizes that our users are humans, just like us.

Design elements typically thought of as polish (e.g. animation, interaction design, surprise & delight elements) aren’t something we add later - they are essential raw material of the experience.

We design and ship courageously, leading with the change we want to see in the world.

When designing experiences with multiple valid behaviors (e.g. should flexible holds be booked over focus time), we lead with our opinion, but provide the user a way to modify behavior we know may be controversial.

Our opinions are balanced with a respect for the trust our users have given us. At worst, our opinions should feel inconvenient - never catastrophic.

We design collaboratively whenever possible, because our best work comes from iterating on and remixing each others’ ideas. Our default approach is to reuse existing components.

We design primarily for the now, but make choices that preserve our ability to scale. When this approach meaningfully degrades the experience, we’re willing to redefine components as an investment in our future.

Product Principles at Clockwise

Clockwise Product Principles

What are Product Principles?

Clockwise Product Principles

Product Development Principles

Sign up to see more