# What I'd do differently today as a product designer

_Two designers, an open brief, and a question we answered far too late. We asked how the product should work. We never asked whether it should be built at all._

By Arely Rivera · 15 Sep 2026 · https://arelyrivera.com/writing/what-i-would-do-differently

A few years ago, I worked on an experimental project.

There were two of us as Product Designers, and we received a fairly open idea: we had to research, design the product, and figure out how to bring it to life.

There was no clear product direction. We did not have anyone leading strategy, nor a technical counterpart involved from the beginning.

So we did what we knew how to do best:

- Research
- User interviews
- User flows
- Feature definition
- Branding
- Interactive prototypes

And considering the context and the experience we had at that time, I believe we did a solid job.

Looking back, however, I realize we were answering a question far too late in the process.

We were asking ourselves:

**How should this product work?**

We never asked ourselves:

**Should we build this product in the first place?**

That single distinction completely transformed how I understand Product Design.

## User research is not the same as market validation

Our research produced genuine learnings.

We understood users better, along with their pain points, expectations, and the features they found valuable versus those that mattered far less. We even uncovered fundamental insights about the experience they expected.

For example, they explicitly wanted a native mobile app.

Even though we were gaining a deeper understanding of the user, we never validated the business opportunity behind the product.

- We did not test willingness to pay.
- We did not try to assess whether sufficient demand existed.
- We did not define what evidence would justify continued investment.
- We did not establish what evidence would indicate we should stop.

At the time, I did not even view those types of questions as part of my job. I understood my responsibility primarily through the lens of UX: understand users and design a great solution for them.

Today, I see a distinction that has become foundational for me:

**User research helps you understand the problem and the user experience. Product validation helps you decide whether there is a business opportunity worth pursuing.**

You can have evidence that a problem exists and still not have a viable business.

You can design something users find genuinely helpful and still discover they lack sufficient urgency to change their behavior.

And you can solve a real problem that no one is willing to pay to resolve.

## Then came technical reality

When we finally received engineering support, the project pivoted dramatically.

The developer built a solution that had very little to do with what we had explored previously.

The users wanted an app. We ended up with a web app.

Several core insights we had uncovered during user research were missing from what was actually built.

We were very vocal about this. Discussions followed, accompanied by frustration and significant friction.

Yet, an extremely powerful argument surfaced: **it was already built.**

So the decision was made to press on. It was an MVP. It was what we had. We needed to test it.

In retrospect, I believe we walked straight into one of product development's most common traps: **sunk cost**.

## "We already built it" is not evidence to continue

Once a product exists, stopping it becomes significantly harder. Because new rationalizations immediately surface to explain why it is not working yet:

- Maybe we need more marketing.
- Maybe the problem is positioning and messaging.
- Maybe we need a new landing page.
- Maybe onboarding has too much friction.
- Maybe we need to invest in growth channels.
- Maybe we simply have not found the right acquisition channel yet.

Each new initiative adds another layer of investment on top of the original hypothesis.

That is precisely what happened.

Design kept working. Engineering kept building. Marketing tried to figure out how to position it. Growth drove traffic.

We built campaigns, set up social media channels, crafted new messaging, and tested distinct strategies to make it work. Tens of thousands of people visited the landing page.

Yet, the product was not finding sufficient traction.

Today, I believe a far more uncomfortable question was missing:

**What would have to happen for us to accept that this hypothesis is not working?**

We do not just need criteria to decide when to continue. We also need **kill criteria**.

Before launching an experiment, we should be able to state explicitly:

- If X happens, we continue.
- If Y happens, we iterate.
- If after a set amount of time, budget, or iterations we do not see a strong enough signal, we stop.

Stopping does not mean the team failed. It often means we learned enough to avoid sinking further resources into an opportunity that is not proving sufficient value.

## The project was not a waste

Here is an important caveat: I do not view that experience as a total failure.

It was an experimental project, and precisely because of that, it gave team members room to try new things. Design, engineering, marketing, and growth all had space to experiment. We mastered new tools, processes, and collaboration frameworks that proved valuable on subsequent projects.

In that sense, it generated real organizational value.

What I would change today is not the act of experimenting. What I would change is **how much I would invest before gathering sufficient evidence to justify the next step.**

## Today, I would start by de-risking

If I were handed the exact same idea today, I would not start by designing an application, nor would I start by writing production code.

First, I would identify what would need to be true for this product to succeed:

- Is there sufficient demand?
- Does the problem carry enough urgency?
- Is there a true willingness to pay?
- Can we reach those target users efficiently?
- Can we build a profitable solution?
- Which of these assumptions poses the highest risk to the idea?

I would start right there.

My primary goal during early stages would not be producing more artifacts. It would be **reducing uncertainty with the smallest possible investment.**

## I would design experiments, not necessarily products

Since this was a B2C product, I would likely begin with something very lightweight:

- Social media content
- Varied value proposition messaging
- A campaign with a strictly capped budget
- A targeted landing page
- A waitlist
- A fake door test

I might even attempt to presell the offer before building any product.

From day one, I would define how much time and capital I am willing to spend to learn. For example: a set budget cap, a tight experimentation window, and two or three rapid iterations before making a go/no-go decision.

The goal is not to prove my idea is right. It is to uncover sufficient evidence to decide whether it warrants a next round of investment.

If the evidence does not materialize, we stop or pivot the hypothesis.

## AI makes this mindset even more critical

There is a massive shift today compared to when we worked on that project: the cost of creating software has plummeted.

With AI, I can spin up a functional landing page in minutes. I can turn an idea into a working prototype with actual logic. I can generate variations of value propositions instantly. I can even build a functional experience to test with real users long before committing to production code.

When execution becomes significantly cheaper, **the bottleneck shifts from production capacity to strategic discernment.**

The core question is no longer just:

**Can we build it?**

Increasingly, the decisive question is:

**What should we build, and what evidence do we have to justify doing so?**

AI should not become an excuse to output more products no one asked for. It should empower us to create cheaper experiments to figure out earlier which ideas are not worth building.

## How my view of seniority has evolved

One of the biggest differences between how I viewed my work then and how I view it now comes down to seniority.

At the time, I received an idea and believed my core responsibility was to execute it well from a design standpoint. That was reasonable given my experience and role back then. It would be unfair to look back and expect my past self to possess knowledge I had not yet developed.

Over time, my definition of Product Design expanded.

Today, I cannot evaluate a decision through a UX lens alone. I naturally weigh:

- Business viability
- Growth dynamics
- Pricing models
- Technical feasibility
- Operational cost
- Time to market
- Distribution strategy
- Team capacity
- Risk profile
- Product strategy

Faced with a new idea in the past, my initial question was usually:

**How do we design this?**

Today, several critical questions come first:

- **Why should we build this?**
- **What has to be true for this to work?**
- **What assumption could kill this idea?**
- **What evidence do we need to proceed?**
- **What is the cheapest way to obtain that evidence?**
- **What conditions would lead us to stop?**

To me, that shift represents the core of seniority: not crafting more complex UI interfaces, but cultivating the strategic judgment to decide **where it is worth investing the team's time before moving a single pixel.**

## Product design does not always start with design

UX still needs to remain deeply grounded in user empathy.

However, Product Design, particularly when participating in strategic decisions, must evaluate a much broader ecosystem.

Sometimes the dominant risk is desirability. Other times it is viability, feasibility, distribution, or simply determining whether anyone will pay for a solution.

The crucial thing is never assuming that the uncertainty inherent to our specific discipline is automatically the most critical risk the product faces.

That is precisely what I missed early on. My work does not always start by designing the solution. Sometimes it starts by helping discover whether we should invest in it at all.

A great user experience costs time. Building it costs money. Distributing it costs even more. And no amount of design, engineering, marketing, or growth execution can rescue a hypothesis that never validated its core premise.

Looking back, that remains my biggest takeaway:

**Before investing in building the product, invest as little as possible to discover whether it deserves to be built.**