And what you need to actually make it happen effectively on an organizational level.

Overview

I’ve been doing this for a long time and I can tell you from experience that real, good product design is one of the hardest things that an organization can do.

Whether you’re just starting out, or a seasoned product professional looking to up their product design game, this article is for you.

Today, we’re gonna talk about what you need to actually make it happen effectively on an organizational level.

Why product design sucks

Before we get into how to fix it, we need to talk about why product design sucks in the first place. In a word, it sucks because it’s hard.

In more than a word, it sucks because it’s inherently complicated and most teams don’t actually know how to do it properly.

This is no fault of their own; most teams “get into,” product design out of necessity in an effort to compete with SaaS giants who have begun to infiltrate their respective industries and hijack their market share.

They actively attempt to package their normal services up as a product, and in doing so, end up botching the process to the point where they either:

• Have to pivot back to doing what they were doing before at a significant loss, or
• Have to close up shop because they ran out of runway.

The bottom line here is that effective product design is not anywhere near as easy as many “design gurus” would have you believe, so to fix this, we need to fundamentally change your understanding of what a product actually is.

What a product actually is

Most teams lack a formal definition of what a product is, and that’s half the battle when it comes to creating one effectively, so let’s get clear on this:

• A product is a packaged set of outcomes backed up by service.

You do not have an effective product without service, period.
It does not exist.

Case in point: if your iPhone is shot, who do you call? Support team. Windows causing problems? Support team and tech team.

Bagel dispenser not working? Support team, possibly dispenser technician, and finally escalating to bagel retention specialist where they will attempt to either help you get a replacement bagel dispenser to keep you as a customer, or even upsell you on a newer model bagel dispenser.

You see what I’m talking about here.

Almost every organization envisions a product that they can infinitely scale without organizational intervention on behalf of the customers and I’m telling you that modern products like that don’t exist.

→ Now that doesn’t mean you can’t sub it out. For example many car manufacturers basically gave the job of fixing their cars to independent mechanics, and many product producers sub out their feature sets to micro-services, but the fact still remains: service will always be part of the equation, and that’s where most products fall short.

At 1:1, it’s easy, but even a shovel is backed up by a manufacturing service, without which, the shovel would not exist.

Moreover, who does that customer go to if the shovel breaks? Is is covered under warranty? How will they get a new one? What is the cost breakdown for that and can you make it profitable?

Now multiply that by 1000x or more, and you have the complexity of creating a digital product, because its not just operating at 1:1 (customer to service) it’s one-to-many at scale.

With physical or digital products, including SaaS, you can scale much further than you can with a traditional service because you have effectively decoupled your customers from your services directly, and are using your product as a front-end for your services.

You’ve replaced the systems and outcomes of your services with a product that encapsulates and delivers that value to your customer directly.

This is true for all products, and it’s one of the many reasons why there are so many products on the market to date, because they can be manufactured both physically and digitally, distributed, marketed, and sold at a massive scale.

More scale = more customers served = more money = more profit, and that’s exactly why SaaS and digital products are currently stomping the yard where traditional businesses with service offerings are failing.

How to make product design suck a lot less

There are some very important points which we need to address in order to create modern, scalable products effectively.

#0 You need to smoke test your product idea

If I had a nickel for every time I’ve asked organizations “how do we know your customers will buy it,” and they’ve looked at me with blank expressions, I would have roughly $2.35. Not a lot of money, admittedly, but that’s not the point.

The point is that most orgs haven’t actually created a product before.

What they end up doing is getting some type of idea for a product somewhere along the line, and decide to build it skunkworks-style without ever testing their product idea on their target market because “customers don’t know what they want.” Right.

• Do people actually need and want what you’re offering?
• Do people actually care, and is there a real emotional impact?
• Will people actually buy it?

Listen, if you smoke test it and there’s no market interest or intent to buy, you might as well just skip it. If a customer isn’t going to click the “buy now” button on a product offering, you have little hope of getting them to buy the real thing.

→ Save yourself the time and money, smoke test your idea against your target market first.

#1 You need a dedicated product team

No surprise here, but you would be absolutely shocked to learn that most organizations trying to build, market, ship, sell, and support a product don’t actually have a dedicated product team.

What they have is a dev team that is working normally on fulfilling the organization’s regular services, who the organization then attempts to shoehorn into being a dev team for the product as well. Not good.

Your regular devs will have their attention split six ways from Sunday. No one will know what’s going on, there will be no separation of concerns, everything is everyone’s problem, until the entire project catches fire and burns to the ground.

You need, at a bare minimum, one of each of the following specialists on your product team:

• UI/UX and/or product designer
• Front-end or native developer
• Back-end or server-side developer
• QA/QC specialist
• Product manager

If you do not have all of these roles filled appropriately, onboard until you do. It’s not just “nice to have,” it’s mandatory or your product will fail.

→ In short: keep your product team separate from your regular dev team, fully focused on designing, devving, and QAing your product, and for the love of God, once you’ve placed them, don’t move them around.

#2 You need a dedicated product support team

Outside of your product team, you need a dedicated product support team who will field the questions, concerns, handle tickets, take down information, route errors back to the product team, and deal with all of the customer support issues that will arise as a natural result of having a product.

Again, most organizations try to put this back on their product team, or somehow make it part of their office personnel’s job. If you do that, and your product fails, I have absolutely no sympathy for you, whatsoever, and here’s why:

You product team is NOT TRAINED on how to be support specialists. You cannot expect a group of devs or office workers to effectively support your customers or route errors because they already have full-time jobs doing what needs to be done for regular business operations.

No, the “many hats” myth needs to die, be buried in the mausoleum of abject failure, and never be resurrected for the sake of “cost control.” Trust me when I say, you will loose ALL of your money if you don’t keep your teams, roles, and operations well-defined.

→ Don’t skimp. Have a dedicated product support team, so that when you scale, you already have the systems in place to keep things rolling effectively.

#3 You need a dedicated triage/fireteam

This one is less obvious but still incredibly important in terms of your product’s overall success in the long run.

At some point there will come a time when something goes absolutely haywire and you need people on it yesterday. This could be anything from infrastructure to codebase issues, but it needs to get taken care of as soon as possible.

• Your dev team can’t do it. They’re already working on changes to the product that have come back from support.
• Your support team can’t do it, they’re not the product team.

So what do you do? Enter the triage/fireteam.

The whole purpose of having a product fireteam is for when sh*t hits the fan. Every minute down is a customer lost, and you need to get back up and running as fast as possible.

“But Nick,” I hear people start in, “keeping people on payroll is expensive and problems like that don’t really crop up all that often…can’t we just have dev take care of it?”

No, because what will happen is that eventually you’ll get to the point where your dev team is JUST PUTTING OUT FIRES, ALL THE TIME, and not actually working on improving your product at all.

→ Look, I get it. You’ve got stakeholders to appease and a board to answer to. If you need to sub things out to save money, this is where you can start doing it, but please don’t skip it. I’ve seen enough orgs that have, and most of them aren’t around anymore.

#4 You need a marcom & PR team

More to the point of actually getting your product in the hands of your users, you need a marcom and PR team.

Do they need to be in-house? No, but they should be very familiar with your product, associated services, offerings, presentation, and market messaging used to connect with your users.

Macom = Marketing and Communications, and their entire job is to make sure that your target customers are:

• Aware of the product that you’re offering.
• Informed of the advantages, unique selling points, and specific reasons that they’ll absolutely want the product.
• Excited for your product offering.
• Better equipped to make an easy, informed buying decision, and know exactly where and how to purchase your product.

PR = Public Relations, and their entire job is to smooth things over with your customers and the media when the fireteam gets called in. They work to spin things in a positive light, ease product perceptions, and facilitate a better overall public ethos of your product, and company on the whole.

→ Again, sub these out if you need to, but don’t skip them. These teams are both incredibly important because they allow you to horizontally scale, grow your market share, and claw back customers that may have been previously lost to your competitors.

#5 You need to clearly ID and systematize your product services/personnel

Finally, you need to clearly identify exactly what your product services and personnel cover, how they interact, any byproducts thereof, and who is in charge of what, when, why, and how.

You need a clear, consistent picture of how all the pieces fit together, or people will absolutely get confused if they’re constantly jumping across role definitions.

→ Your team is not single-threaded. You can’t perform asynchronous tasks without integrated automation and systems that support your daily operations. Flying by the seat of your pants in product creation will not cut it, systemize your operations or perish.

Expense is par for the course, plan accordingly

Let’s talk expense. Most people aren’t ready to hear this, but especially in light of everything that we just went over, it should come as no surprise that creating a successful product is astronomically expensive in both money and time.

Gone are the days of moving fast and breaking things. Customers expect products that are quick to the point, get the job done right the first time, and don’t leave a mess for them to clean up.

You are not up against independent developers, you are up against monoliths, which means you must be absolutely dogged and relentless in your pursuit of creating something:

• Uniquely valuable to your target customers
• Uniquely positioned in your market space, and
• Uniquely presented to your customers

When I’m designing a product, I’m not worried about the immediate costs, because no matter what I do, it’s going to cost money.

No, I’m much more concerned about the long-term earnings of that product, and the inherent market viability of such, not just in the next five months, but in the next five years.

→ You need to aim for a profitability margin of at least 20–25% because you can bet that some of that margin is going to get eaten alive adapting to market changes.

Bringing it all together

So what exactly does this all mean for you as a designer? How can you best ensure your product’s success on an organizational level?

1. Smoke test your product ideas before you build.
2. Make sure you have a dedicated product team.
3. Make sure you have a dedicated product support team.
4. Make sure you have a dedicated product triage/fireteam.
5. Make sure you have a Marcom and PR team to help you get
   your product sold.
6. Make sure you have clearly identified and systematized your product services/personnel.
7. Expect and plan for the entire process to be expensive in money, time, and resources. Keep your margins high, and your turnarounds fast.

Outside of this, if you’re looking for information on how to design an effective product, I’ve got a full guide for you right here, for free: