Everyone at Shopify works on product.

It goes without saying that your product should help fulfill Shopify's mission to make commerce better for everyone. But when you're faced with multiple options that all seem to fit the bill, how do you pick the right one?

When you come to a fork in the road, use one simple rule to make the most informed choice: take the path that leads to more entrepreneurs. Choose the option that allows us to enable entrepreneurship for more people.

Here are some questions to ask yourself when presented with multiple paths forward:

• Will one of these choices lead to more entrepreneurship in the world?
• Does one of these paths put Shopify closer to its stated goals?
• Will this decision unlock more options for the company down the road?

"You can't forge great things at room temperature." — Tobi

When you aim really, really high, you'll find that there's actually less competition in that space. Almost everyone decides to aim lower because they believe it's more attainable — but that means there's actually lots of competition at lower levels.

If you, like Shopify, aim to holistically solve an entire problem, you might be the only one attempting it. If you say, "let's just make this one small area a little better," you will be one of many.

Every product we build should be as ambitious as possible without becoming a side quest. There are many different types of ambition we could reach for. Does this product have the potential to add millions of new merchants? Could it change the face of commerce? Does it allow us to align with strategic partners? Be sure to define specifically what your ambition is for your product, and incorporate it into your Green Path.

Once you've begun to build, get it working and ship it quickly. Momentum is everything. Iterating on real-world feedback is more valuable than expanding the scope of what you'd like to achieve (to become more ambitious). Also, set yourself up for success so that you won't have to narrow the scope of what you're building mid-way through development (to become less ambitious).

Ambition, of course, needs to align with reality. Teams need to know if their work has impact. They should constantly measure, reflect, and evaluate progress.

In the process, you may discover a more direct or elegant route to your destination. When this happens, have the courage to start over. Reject the sunk cost fallacy. When a clearer path emerges, reset your trajectory – even if it means starting again.

Doing your very best to avoid the ambition decay that comes from discovering just how hard it is to do what you set out to do. Building great products requires a certain exothermic-ness. The ability to inject heat into a project to build momentum, and prevent stasis. Focus on getting closer over time; on building energy by taking small steps along your Green Path. This will always lead you to something better than having compromised your ambition.

The best software products in the world always have the same thing in common: they turn something that was once incredibly complex into something approachable. We want to enable pro-level power while maintaining newbie approachability.

It's easy to make something complicated. It's much harder to make something simple. When you have something simple, you can make it powerful later. When confronted with something already powerful and complex, first we do the hard thing – digest the complexity of a system and deliver it to users in the simplest, most approachable way possible. One that requires the least cognitive overhead. Later, we can add more complexity and power for the much smaller and more advanced group of users that want and need it. Don't reverse this order. It's almost impossible to reverse later.

To take a Shopify example, let's look at how layers enable our Theme Editor to work for beginner, intermediate, and advanced merchants:

Beginner: When someone signs up for Shopify, they see a storefront, already set up and ready for them. Our defaults are really good. What comes right out of the box is what most people need. If the defaults aren't quite enough, merchants can go to the theme store and choose a different theme with a couple of clicks. Shopify's Theme Editor has one-click options for simple things like adjusting color palettes, implementing dynamic product filtering, and integrating video backgrounds. The potential for a merchant's store to match their brand's look and feel is important to most people, so we've made it easy for everyone.

Intermediate: Those who want to customize the design of their store (tweaking the layout or font size, for example) can use the Theme Editor to make those changes easily and immediately.

Advanced: If there's still more they'd like to customize, they can use Liquid, Shopify's open-source template language. With Liquid, merchants get tons of power — they can see the html and accomplish essentially anything they want. Or, they can hire a Shopify Expert to make those changes for them. With a framework like this, merchants can transform their vision into a storefront that rivals enterprise-level sites – without writing a single line of code. The amount of effort they need to invest is directly proportional to the magnitude of the changes they want.

It's so important that we keep Shopify approachable. Until the moment a merchant makes their first sale, all the work they put into setting up Shopify is of negative value to them. We demand both their time and money, so it would be disastrous to scare them away before they start to see benefits. People tend to give up when software makes them feel inadequate, or makes them feel as though they're not smart enough to be an entrepreneur. Let's do our very best to make sure our merchants never feel that way. Let's also do our very best to keep their onboarding experience, and every moment leading up to their first sale, as approachable as possible.

The ideal way to solve problems in the commerce space is through layered, highly technical, but incredibly accessible through the powers of UX design systems, where every piece is independent.

We want our merchants to experience Shopify's layers from simple to advanced, but in order to make good design and infrastructure decisions, we need to build it the other way around. We start with the advanced layer (a commerce data model and infrastructure for features), and then work backwards to create a simple, default product experience on top of it.

That means it's vital that you are aware of all the capabilities of the infrastructure in the product area you work on. If you're thinking of building a new feature or experiment and there isn't yet infrastructure to support it, you'll need to invest in building that infrastructure foundation first. This is non-negotiable. Strong infrastructure is what allows us to scale quickly and build reliable products that stand the test of time. Without it, we risk creating technical debt that will slow us down later.

However, when you deeply understand your area's infrastructure, you'll be able to find clever ways to make what's already there work for you.

If you see a building with a broken window, soon you may notice all the windows on that same street are broken. People will assume that the act of breaking windows goes unpunished in those parts. It becomes the standard.

Similarly, people make natural assumptions about an environment based on a single example of something wrong with it. Any negative experience, or "broken window," that a user encounters can harm their perception of the entire product — even if the other 99.9% works flawlessly. Our merchants' trust in us erodes whenever they encounter a flaw.

Say a non-English speaker opens a Shopify store and goes through the first few onboarding steps in their native language, then comes across a Home card that's still in English. That's a broken window. If they encounter a bug, like a page that didn't load right, or a submit button that's unreachable — all of these things drain the trust battery and discount the overall quality of everything we've built. Our product is only as good as our worst user experience.

It's better to build nothing than to build something shitty and leave it that way. When you encounter broken windows, it's your job to help fix them. Even if you had nothing to do with the broken window in the first place, it's our shared responsibility to prevent more merchants from encountering it and having a trust-eroding experience.

Consider even the tiniest details, and make sure they create only the best possible experiences. Consider things like user interface (UI) animations or integration enhancements — these small details are what most people mean when they talk about "delight."

Shopify's quality bar goes beyond fixing broken windows, and involves anticipating what our merchants need. Simply being functional is not enough. Our products should be enjoyable to use, intuitive, and seamless.

When someone signs up for Shopify, they should never be able to figure out the order in which we built our features, or which team built them.

That's a barometer of good software: the moment a product launches, it seems as though it's always been there. You can't reverse engineer it. You would never be able to tell that the Storefront Editor or Shopify Payments, for example, weren't there from the very beginning. Our history should never be obvious. Everything should weave together seamlessly, regardless of which team shipped it. Our product should be holistic, with each part interconnected purposefully.

Shopify merchants may be varied, but we should always provide a single, great experience that solves their problems. There's only one Shopify product. When we can't create a general experience, we should create a specific experience that solves the problem — but it shouldn't feel unfamiliar or like a whole new product.

Our approach to internationalization is a good example of this. When we encounter an area where Shopify doesn't work for a specific market, we extend the product. We localize with regional payment and shipping providers, channels, and languages, but the core product always remains the same. Everyone at the company works on the same Shopify. Our software is flexible enough that we can customize it for a special market without having multiple country teams working on entirely different products.

There's one qualifier to this principle: don't surprise people. For anything more complex than autofilling fields, don't do things for merchants — rather, offer to do it for them. "We noticed you've been doing [task] a lot. Would you like us to continue doing that for you?" We don't make our merchants' decisions for them. What we do is offer them high-quality direction and guidance that they can choose to act upon.

Additionally, make Shopify a predictable and clear experience. Don't automatically implement custom user interfaces based on usage. If someone has 10 different Shopify stores, we don't want them to have 10 different-looking Admins. People should have the choice to change the look and feel of their dashboard, but we shouldn't make that choice for them.

There is a tension between keeping things simple and approachable and oversimplifying the information they need to be successful in their business. They should not need to be masterful in using Shopify, but using Shopify should not prevent them from mastering commerce.

While we are judicious in how we leverage data for decisions, this is not an excuse to overlook the careful collection of data. We must be obsessive about gathering data that shows how our merchants and their buyers use our products, while always keeping the privacy and security of that data top of mind.

If we don't collect this data from the very beginning, we lose our ability to replay the past and learn from it. If we do collect this data, it allows us to continue to move in the direction of our Green Path.

Here are the most common compromises we evaluate each time we build a product:

• Quality: How much will we invest in the user experience? Are we looking for just simple, consistent experiences? Or are we aiming for blow-your-mind, inspired designs that build on our reputation as industry leaders? How much will we invest in the code? Does it just need to work, or does it need to scale and be infrastructure for many more features down the road? It's important to think of quality as a spectrum, and not something binary.
• Time: How long are we willing/able to invest before we need to see an impact? What key milestones or calendar events are we tied to for launch, if any? Are those arbitrary deadlines, or is it important that we ship within a certain timeframe?
• Scope: How deep of a feature set should we include before launch? What are the essential components that need to be incorporated, versus the nice-to-haves that could be abandoned or happen in a later version?

How do we know when a product is "done"? When it does the job it was meant to do. It may only have about 80% of the features it could potentially have, but those 80% should work incredibly well, be the most valuable 80%, and solve an important problem affecting our merchants.

A common industry term for this is Minimum Viable Product (MVP), but that can lead us to think that poor quality is acceptable. It's not. Everything Shopify ever produces should work extremely well. No merchant should ever feel like they're using beta software, wondering when we're going to improve a half-baked product. Instead, they should be delighted by our MVP, and even more delighted as we continue to improve the product and experience over time.

As an example, the MVP of a car is a tricycle, not four wheels and a seat. Ship the tricycle, then the bike, then the motorcycle, then the car. All of these steps are along the car's Green Path.

Everything should be built to last and evolve, instead of just being "good for the first step." No code is meant to last forever, but all code should be able to fold into any new requirements; into the next step down your Green Path.

When we shut down Sello (a mobile app allowing merchants to sell through social channels), it may have looked like a failure at first glance. On the contrary, it was one of the most important things we've done in recent years.

Why? It led to so many discoveries and learnings. We now understand mobile better. We discovered GraphQL (a query language for our APIs). We learned how to improve Shopify POS.

This experiment replaced every cell in Shopify's body. We are completely different because of it. Sello was not a failure, but rather a successful discovery of something that did not work. We can apply those learnings to make every other product better.

Here are few of the lessons we learned from Sello:

• Have a clear hypothesis you can focus on. Sello attempted to tackle three challenges at once: To create a new mobile tech stack, to develop a new mobile product, and to make Shopify mobile-first. Having multiple objectives slowed the team down, and prevented their hypothesis from being testable.
• Make sure people know what your product does. Most Sello users assumed it was similar to a marketplace or a Classifieds section, where they could discover other products. When users' expectations aren't met, retention rates are low.
• Beware the sunk cost fallacy. Despite low product adoption rates, the Sello team felt the need to continue because they'd invested so much time and so many resources into the project. We should always be ready to abandon projects or pivot drastically if we have evidence that an experiment is on the wrong track.

Local maxima is a mathematical term, but the easiest way to understand it is to imagine you are climbing a mountain. You're trying to get to the top; the local maxima. Sometimes though, when you get to the top of that mountain, you see a much larger mountain behind it, the tallest mountain of them all – that's the global maxima. It's rare for companies to make a deliberate effort to climb a mountain that high. It's a painful exercise. But we're up for the challenge. We're not interested in limiting ourselves to the local maxima, we're looking to conquer the global one.

The problem is, when we're climbing a mountain, we don't always know which one we're on. We've committed to multiple projects that didn't allow us to reach the heights we thought they would, and we had to be willing to scrap all that effort, turn around, and start all over again.

To give a Shopify example, we were climbing Mount Online Store for a very long time. At some point, we decided to purposely walk back down that mountain, and climb Mount Multichannel instead. Before that, no one even knew Mount Multichannel existed. You had to be on top of Mount Online Store to even see it in the distance.

Any mountain takes energy to climb, so we might as well choose the biggest one. Otherwise, we're wasting our efforts.