What *product* really means (plain english)

Industries love to navel-gaze. The product design world is no different. We use product to mean a lot—helpful inside the industry, confusing everywhere else. Product—in plain English—means software design, development, and all the supporting tasks around it to make that software a success.

The term product is used by those in our industry to cover the entire lifecycle of bringing a piece of software to market. It also implies that the software either generates revenue directly or supports a larger paid service.

As I mentioned, using product over software is useful, as the product development process covers far more than just writing code. To me, product design can include everything from research and planning to design, development, and ongoing support:

• Strategy: Market definition, pricing, roadmap planning

• Design: UX, content, and service design

• Build: Architecture, development, QA, testing

• Support: Launch, training, help desk, analytics, maintenance

Once you finish that process, you start again—products are never finished. 

It’s important to point out that not every product needs to cover all those steps. And some passes through that process will be shorter than others. But you can see that the single word product is doing a lot of work. 

Why the distinction matters

Here’s why the distinction between software and product is important. Let’s say you have an idea for an app to support the members of your organization. If you treat it as software, plenty of shops can build it for you. Maybe it works—but that’s rare. 

More often, the idea is solid but misses something: user needs, technical limits, or organizational readiness. Maybe people don’t want to interact as you imagined, or your vision was too big for a v1. These are the issues a product approach uncovers early. That’s why we think in terms of products, not just projects.

Thinking through a product lens gives us the bigger picture. 

Some clichés capture it well: 

Measure twice, cut once.

Go slow to go fast.

Haste makes waste.

Or my favorite (somewhat apocryphal) quote from Bill Gates:

People overestimate what they can achieve in a year and underestimate what they can achieve in ten.

The takeaway isn’t that product design is slow—it’s methodical. It may feel slow at first, but that patience prevents rework, throwaway code, and technical debt.

From that point on, every improvement compounds. Trust your product team to be the experts in how you build, while you stay the expert in why it matters. That’s how great products—and partnerships—work.