Everyone is Building Something

Why you should treat your work like product development

At one of my jobs, I took on (well… aggressively pitched for 4 months) a reorganization for a Product-Tech function. The company had scaled quickly, and despite its continually strong growth, organizational maintenance lights had started going off.

The learnings from that project are a story for another time, but the project was a watershed moment in my career: I’d never built anything so important for a group of people I knew so little about. 

For an entire summer, I spent hundreds of hours reading articles, books, and case studies about software engineering, product design teams, and product development. Each evening, I would pace up and down the West Side Highway while listening to podcasts and audiobooks to try to understand the type of teams I was restructuring. I pestered coworkers, interrogated engineer friends, and did everything I could think of to understand the people in these organizations.

The research was useful for delivering the reorg, but it also had an unexpected and outsized impact on my broader approach to work. Every time I learned something about how to be great at building products, it was clear that I was also learning secrets to being great at building anything. 

And whether we describe it to ourselves this way or not, we’re all building something. 

FYI: You’re Building a Product

Regardless of where you sit in an organization, if you’re in a role that owns a project or program of any type (or a piece of one), you are working on a product. Your customers might be your coworkers, and you probably call your product development lifecycle a change management or project management framework. But regardless of how you describe it, your work still involves picking, designing, testing, and launching something for someone else to use. Kind of sounds like product development, no? 

However, most non-product functions don’t think of themselves that way, or at least don’t talk about themselves that way. At best, this means that they’re missing critical value-creation opportunities. But at worst, it keeps organizations trapped in vicious cycles of stale and inefficient ways of working.  

Take performance management programs as an example. While more and more companies are questioning traditional features of the performance management process like PIPs and annual reviews, for how hated and ineffective these programs often are, we’ve made little collective progress toward building something better. 

Well-meaning HR practitioners across industries have spent countless hours lamenting the shortcomings of performance programs and trying to design more effective processes. However, most continue to produce improvements that are only fractions of degrees better than the status quo. While this stagnation happens, in part, because it’s genuinely hard to build a great performance program, industry-standard approaches to building HR programs are also partially to blame. 

Those approaches often look like something I learned the uselessness of when trying to benchmark org structures. When I began planning the reorg, I started with what felt like the intuitively correct first step: looking up other companies’ org structures. Two pizza rules, squad models, functional reporting structures… there is no shortage of org inspiration to be found. Naively, I inhaled information about all of them, trying to find a blueprint for structuring my own org. In short, I followed the all-too-common pursuit of trying to find a “best practice.”

The Best Practice Trap

To put it plainly: “best practice” is a veiled, bullshit piece of corporate-speak that really just means “other companies that make money do things this way.” 

While it’s likely true that whatever “best practice” looks like in your industry is working for somebody somewhere, it is a dangerous telos for a builder. What works perfectly in one company can be a disaster in another. Even within one company, what works one year might not work the following. 

Still, peek into any number of support function meetings (or internal docs of mine when I was trying to learn about org structures) and you’ll find that this ephemeral idea of “best practice” drives much of the work that is done in companies across the world. 

To be clear: there is nothing inherently wrong with drawing inspiration from others. Where the pursuit of “best practice”  fails to produce business value is in its orientation around something conceptual, something that makes sense when you describe it but not necessarily when you do it. 

This pursuit is also an illustration of the risks of building a product without realizing that’s what you’re doing. You can design, test, and launch on time and within budget, and you can even get the concept really right. But you’ve still ignored the most crucial step in building something great — understanding your customer.

FYI: You Have a Customer 

Here’s the most important thing I’ve learned from studying product development: in order to build anything of real value, you have to know a lot about who you’re building it for. 

While support function employees spend hours learning about the philosophies and justifications behind the things they build, they often spend only a fraction of that time learning about the humans who use those things. Think about how many HR people you know who could describe a day in the life of one of their company’s engineers. What about strategy managers who inform company direction with a deep understanding of what it’s like to work in influencer marketing or customer support? Even for product-minded employees who do this stuff for a living, how many data science or design leaders do you know who can clearly articulate the daily experiences of the people on their teams? 

All of us have a customer we build for. And as far as I can tell, all of us would benefit from knowing them better and making them more central to the way we work. 

Tips for Approaching Work with a Product Mindset 

While I am by no means an expert in product development, approaching my work like I’m building products has drastically improved my ability to create processes and programs that people will actually use. There are tons of great principles and learning to be drawn from the product people of the world, and if you’re one of them, I’d love to hear your advice. What I can offer you now is the list of five product ideas that have proven most valuable for me: 

1. Always start with the customer problem you’re trying to solve.

Begin every project by clearly defining the problem your customer is facing. Not the symptoms of the problem and not general ideas of challenges that you know lots of companies have. Ground your work in tangible proof that the people your work goes to are legitimately struggling with something, and be diligent about following proximate issues to their root causes. When you start with a genuine problem to be solved,  your work gains a mission instead of just a project plan, and you’re more likely to build something worth using.

2. Obsess over your customer.

Not sure who your customer is? Think about who “uses” your work and what they use it for. If you’re a leader, your customer is almost always your team, and if you’re a lower-level employee, your customer might be your manager. Whomever they are, figure it out and become healthily obsessed. What are their preferences, hurdles, and experiences like? What does success look like to them? What do they care about more than anything else? How do their ways of working shape their needs? To build great products for the people you serve, make cultivating an understanding of your customers a routine part of your job. And don’t just learn about them once and be done. Just like your needs and priorities change, so do your customers’. Never stop figuring them out. 

3. To make something better, get it into your customer’s hands as soon as possible

One of my New Year’s Resolutions this year was “no more grand reveals.” I’d fallen into a habit of building things in the dark for weeks or months and then unveiling them all at once.

The very first hour of learning about product development taught me that this approach is usually wrong.  Whatever you think will happen when you launch a deliverable into the world is at best an approximation of what actually will, and the faster you can get your work into the hands of the people who use it, the better you’ll be able to make it. Sometimes that means explicitly saying that you’re sending out a half-baked potato. But whether by committing to starting with MVPs and pilots or bringing your customer into your build process, know that no matter how much you know about your discipline or how good your idea seems, no amount of knowing will serve you as well as good, old-fashioned customer feedback. 

4. Don’t underestimate design and experience.

Whether you build something visual or not, design is not just aesthetic. When you are building something for someone else, their whole experience is a function of the thought you put into design. From the language you use to describe things to the tools you ask people to use to perform tasks, every part of your customer’s experience can be improved by better design. And if you struggle to understand how you’re designing something, just start by asking yourself this: how can I make what I’m building more intuitive, accessible, or enjoyable? 

5. Lastly… Iterate! Again!

Nothing should be precious in a company just because it’s already been built. The journey from good to excellent is paved with iterations, and very rarely is great work done and never revisited. Get feedback incessantly. Don’t be afraid to make adjustments—even significant ones—if they mean better alignment with peoples’ changing needs. Blow up a “launch” if it means building something that will actually work. And if the outcomes are telling you that your efforts fell short, get the feedback and try it again. Do versions 2.0 and 3.0. Do version 9.0 if you need to. Yes, change is challenging and there’s always a cost to introducing more of it. My advice is to do it anyway. Your work is a product not just a set of tasks. Make it one that people will actually use.

Best of luck with whatever you build. 

Thanks for reading,
Kristen