Product promises

user experience

There’s this known thing in the industry… “customer commits” – it’s this concept in which sales teams make promises to customers before making a sale, in order to get a sale. Essentially, they are making a promise to the customer that a certain feature or functionality will be in the software they buy, without any input from design and development teams. Even if that feature does not exist today, the salesperson promises it will included to close the sale.

And what happens to these promises?

They are added to the top of the product roadmap, as a top priority. So, all the other priorities the team is trying to focus on gets shifted, and they have to work to satisfy the promises made by the sales team. This is risky and problematic for every team involved.

Why is this a major issue? Well, I’ve seen many of my clients suffer through this, and not deliver on these important promises because their product teams are stretched too thin. Oftentimes, teams are not organized to handle these prioritization shifts. So things like bugs, usability issues, and backlog items fall down on the list, sometimes, not being worked on for several months or even years because they must satisfy the promises made by sales.

More often than not, your existing customer base suffers just so you can satisfy your newest customer. New product features, enhancement requests and known issues are not fixed because a whole new thing needs to be built. And this is why there are so many bad or half baked products out there. And why even some of your favorite products seem neglected in certain areas.

These are blind promises. Sales people are not always technical. They are not always lock & step with their design & development teams. And they almost certainly don’t know how to properly assess and estimate the work they are promising.

So why do we do this?

Why is this an accepted industry practice?

It’s the classic chicken & egg scenario. Do you make it before you sell it!? Or sell it so you can make it?

My take? People don’t want to be sold to.. When you design great products & services they should sell themselves! Also, people who love what you made will actually sell it for you. If we spent more time building the things we want to promise people, vs. selling things we hope we can build, not only will great products emerge, but happier and healthier teams will, too.

Let’s only make informed promises we know we can keep.

Better yet.. let’s make less promises. And go make the product itself!

Heatherlee Nguyen
TᕼE IᑎᗪIE ᑕOᑎᔕᑌᒪTᗩᑎT
𝗣𝗿𝗼𝗱𝘂𝗰𝘁 »𝗖𝗫« 𝗦𝗲𝗿𝘃𝗶𝗰𝗲 𝗗𝗲𝘀𝗶𝗴𝗻

[The 4 D’s of My Design Process] Part 1: I start with the people…

Heatherlee Nguyen •  IᑎᗪIE ᑕOᑎᔕᑌᒪTᗩᑎT •𝗣𝗿𝗼𝗱𝘂𝗰𝘁 ≋𝗖𝗫≋ 𝗦𝗲𝗿𝘃𝗶𝗰𝗲 𝗗𝗲𝘀𝗶𝗴𝗻•


As a seasoned designer you start developing your own framework for the work you do. Ideally, you follow your well-intentioned design process to a tee, never compromising on the phases or pacing you recommend to your clients.

As a consultant though, joining many different product teams with varying levels of maturity, capital and design thinking, it’s no secret we designers don’t always get to follow our preferred process. We get the job done. We compromise, bending to the budget, the team culture, scope and timing set before us.

At least that’s what I do. I don’t believe there’s one perfect way. I love learning and making new ways work. The work we’re doing deserves openness and flexibility from all team members. As long as we’re following the basic design tenants and applying empathy the process we follow is malleable. That said, here are some notes on my preferred design process. It always starts with the people..

Who exactly? Well everyone. I start with gaining insight into the team I’m working with. Where’s everyone’s expertise, where are their passions, where do our abilities overlap and where are there gaps? I consider the stakeholders. I gauge their expectations, their specific interests in the project/product and gain an understanding of how closely we’ll collaborate. I also learn about the people on the perimeters of my team, maybe outside partners or other internal teams that I may be developing for or with. How will we leverage each other?

Last but certainly not least..

Who we design for. Who we think we’re designing for. Who we want to reach, who we want to impact. One of the main things I do is gain a deep understanding of, and empathy for, those using, affected by, and relying on this thing we’re designing. Who are they really? I consider their lifestyles, their interests, where they live, how they do the things they do, how different and how similar they are from other people using the thing. I interview them, observe them and put myself in their shoes. I create artifacts for the team that keeps this front and center at all times.

It’s ALWAYS, always people first. Just scroll through my blog posts, you’ll see the proof is in the pudding. They are the center of the process. The nucleus, if you will.

After the people I focus on data, defining, designing, and (re)discovering.

DATA: What is it?

I get a close look at the following..

Product History: Is this thing new? If not, how long has it been in-use? Why was it originally developed? What needs does it serve and where is it lacking? What do people like/dislike about it? I take a look at the existing product roadmap (or lack of) to gain as much knowledge I can on how this thing works, what it’s purpose is, what the vision of the team is and where any barriers are.
Analytics: What’s being measured, how is it currently being used? What’s not being measured that should be? Is there an analytics team I can partner with as the project evolves?

Research: How has this thing been researched for? What should now be in place? Is there a research team that gathers and analyzes competitive data and market research? What are the trends? How will we continue collecting research as we move forward?

Once the data is looked at and research has a foundational start it’s time to define some things.

DEFINE: What is it?…… to be continued..

Read more about my process in my next post. Hit the follow button below for email notifications when new posts go live. Thanks for reading!

TᕼE IᑎᗪIE ᑕOᑎᔕᑌᒪTᗩᑎT 𝗣𝗿𝗼𝗱𝘂𝗰𝘁 »𝗖𝗫« 𝗦𝗲𝗿𝘃𝗶𝗰𝗲 𝗗𝗲𝘀𝗶𝗴𝗻

I’m Heatherlee. An independent research and design consultant with a background in UX, a passion for service design, an interest in biomimicry and a stake in your strategy. I’m passionate about helping you bridge the gap between your product teams and the people you design for.

Contact info & more about me here.