Mindset and Core Principles

How to use them to build great products.

Mindset, core principles, and building great products.

When watching American football games on TV, do you pay attention to the music the network plays as they transition to commercial breaks? Are you scrambling for your phone to get Shazam open before the song fades out? Or plumbing your brain for a scrap of memory storing that tune so you can find and listen to it on Spotify? 

To my wife’s ongoing incredulity, I do, and I use those 3 or 4 seconds to recognize a shocking number of songs. Such are the contents of my brain.

One of those musical interludes during this year’s Super Bowl featured this.

Kudos to the broadcast’s music producer because, to say the least, this is a deep cut. Mad Season was a grunge superband made up of Alice in Chains, Screaming Trees, and Pearl Jam members. I had their lone studio album, Above, in heavy rotation from 1995 until, well, still. I immediately recognized the seventh track as one of my favorites from the album.

The song came on, and I was midway through drafting this article, deep in thought about mindset and core principles. Layne Staley was reminding me that ‘I don’t know anything’. It clicked for me that you create a mindset and core principles because you actually don't know anything when you set out to create something. All the hard work, decisions, and forks in the path are yet to come.

I don’t get it. Why are we doing this?

When I was first asked this question as a newly minted product manager, I was sitting in a conference room in Dublin, Ireland. I was in town for roadmap planning, and my interrogator was an older, seasoned developer and the product’s architect. I had no idea how to answer the question.

I’d researched, prioritized, collected feedback, and had a reasonable idea of ‘What’ we should build. I’d flown across the ocean and hand-delivered the requirements.

I didn’t know ‘Why’ we should build those things and didn’t have the tools to figure it out.

We muscled through planning and came up with a roadmap that we utterly failed to execute. Every time we reached one of those forks in the road - should we build a connector for a new customer or extend our data modeling and synchronization capabilities for that upcoming tradeshow demo? - we had no basis for deciding deliberately.

The team hadn’t developed a shared mindset, and we’d agreed on no core principles to help us through difficult conversations.

Mindset is everything, and it’s hard and intangible.

Getting a team to understand and share a mindset might be the most challenging thing a product manager does. When everyone shares a mindset, usually it’s because they all understand the ‘Why’. Why are we building this product or this specific feature, why now, and why for this customer or target persona? How will we know when it’s done? And whether it’s good or not?

When everyone understands the ‘Why’, the ‘What’ comes much more easily, priorities stay focused, adjudicating between conflicting ideas becomes less controversial, the purpose of features is more easily recognizable, and their function is evident.

Core principles make your mindset tangible. They define for the team facts that are always true - we employ test-driven development, use agile methodologies, and build every feature securely - which you revisit as often as needed until they become commonplace in discussions and decision-making. Observing whether or not you’ve applied the core principles becomes obvious. And you can start asking questions like how often features have conflicting goals and how often the application of your core principles led to a resolution.

When something is tangible, you can apply metrics, and when you can apply metrics, you can measure your progress toward success.

So, before you build your product, think about the core principles you’ll use to drive decision-making throughout your product’s lifecycle. Write those principles down and review them with everyone involved in the project. Those core principles, and the mindset they reflect, keep you on track when things become ambiguous. They’ll help in that thorny middle part of your project when you are too far along to see the beginning and not far enough to know the destination.

Core Principles

This is the way.

I’ve formed the habit of writing everything down in priority order. I have a set of principles developed over the years I return to when starting a new product. Since you’ll be using these principles to guide you through tough decisions, make sure each is clear and prioritized.

Here’s my list.

Be secure by default. 

We have a professional and moral obligation to build our software to be as secure as possible. Can my software listen on HTTP instead of HTTPS? No. Can I store the secrets my product needs in the source code repo? No. Can I leave this API endpoint unauthenticated? No. Do I have to encrypt my data at rest? Yes.

Once, a team asked to do a quick workaround instead of properly building in Cross-Site Request Forgery defenses because they were afraid it would be easy to get wrong and hard to maintain. Both concerns were valid and represented the very reason for this core principle. Salesforce exemplified this principle by executives constantly repeating, “nothing is more important than the trust of our customers”.

When forced to make compromises about security, add the feature but make the secure option the default so that your user has to make undoing the secure option a very deliberate choice. Flash warnings - hey, we don’t recommend you make this change or remove this security feature - explaining in clear, concise language the implications and risks of the change. It is the right thing to do and sadly needed in today’s cyber insurance environment.

Go easy on the customer.

I am sure this seems obvious, but I cannot count the number of times I’ve seen proposals to build something that makes it easy on the team but WAY harder for the customer. If faced with the choice between “we can knock this out in a day” or building so that each task is even marginally more straightforward for the customer, always choose the latter. Forcing complexity onto customers eventually adds up and will crush your customers’ satisfaction. Prototype the feature, show it to a customer, and get feedback. Customers will tell you exactly what they want and how they want it to work. Never fall into the trap of thinking you are smarter than them.

Build API-first.

This is an encompassing principle because it addresses product development and delivery fundamentals. Like test-driven development, API-first encourages thinking about several design and implementation considerations. For example, your teams can use loosely coupled architectures with clear abstraction layers to break dependencies and facilitate cross-team collaboration. 

Treat all of your APIs as though they will be customer-facing, even if you anticipate some will remain internal, because then you have to document and secure them properly, and you’ll achieve consistency across your implementations. Make your APIs backward compatible so that integrations, customizations, and security continue to work even when you are making changes to your core platform or product. When building a product with a UI, remember that not every feature needs a UI, but every feature needs an API. You can always add UI later.

Be market-driven.

I hear people talk about how important it is to be customer-driven. Take the time to know what customers want, but always validate what individual customer’s need matches a broader market opportunity, especially early in your search for product-market fit. The balancing act of staying focused on early adopter needs and a broader market opportunity is tough. If you are wobbling on the highwire, take stock of whether you’ve drifted from true product-market fit. 

How do you recognize when you’ve tilted too far toward individual customer needs? Your product resembles a Cheesecake Factory menu, and your features are a mile wide, an inch deep, and often orthogonal to one another. You are committing developers to support your creeping feature breadth and having difficulty prioritizing new work over ongoing support. This principle will help you step back and do the necessary pruning to get you back on track. 

Use Agile methodologies.

Organize into small teams and build what you can articulate in small stories. Move all kinds of testing - unit, functional, scale and performance, and security - as far left in the development cycle as possible. Ship quickly and get direct, targeted feedback from real users. Take those learnings and iterate. Repeat. Release frequently with confidence in quality and security. Measure meaningful metrics so you know how well you perform, where you can improve, and when to make changes. (I use the metrics from the book Accelerate as they provide some objective measures that are primarily non-controversial.)

Other Principles

These five principles apply to nearly all projects. Situationally, you may apply other principles, such as requiring test-driven development, using design and development frameworks in your app development, or employing Objectives and Key Results to drive and track the most important work for your team. Deciding whether you need additional principles depends on what your team needs. What has worked for me is sitting down with the team and having a conversation about keeping everyone on the same page. Let it evolve over the project's life; what you need early on might differ from what you need as the product matures.

This list has worked for me. What has worked for you?