Too technical. Not technical enough.

For years, I was told: “Elena, you are too technical.”

More recently, I heard the opposite: “Elena, you are not technical enough.”

Apparently, there is a narrow space where a product leader is considered technical enough. I decided not to spend time defining it.

Instead, I ran an experiment.

Four days and a deadline that could not move

My daughter turned eighteen in June. I wanted to give her something made specifically for her.

I also wanted to answer a question for myself. After more than twenty years leading product teams, what could I now take from an idea to a working product on my own, using Claude Code?

The birthday gave me a constraint every side project needs: a date that could not move.

I had four days. I shipped on the day.

That first version was not a startup and it was not a product. It was a private gift for one person. It is not shown here and never will be.

A signal is not validation

When I showed it to a few people, the reaction was consistent: “This is beautiful.”

It was good to hear. It was also not validation.

Nobody had asked for the product. Nobody had paid for it. The people reacting knew me.

But it was a signal, and a signal can be enough to form the next question: could the original experience become something other people would want to use?

That is where the product work started.

From a private gift to a product hypothesis

I took an experience designed for one person and generalised it for birthdays, friendship anniversaries and relationship anniversaries.

I added multi-tenant storage, a theme system, a landing page and three examples built with invented content.

One of the three examples: a thirty-year friendship, built entirely from invented content.

Then I tested three pricing hypotheses with a lightweight fake-door experiment.

I deliberately did not integrate a payment gateway. There was not enough evidence to justify it. Building one would have produced more software, but no additional learning.

This is a familiar product principle: evidence first, infrastructure later. Building directly made the cost of ignoring that principle more tangible. It was my own time, my own backlog and my own temptation to confuse output with progress.

Three pricing hypotheses and a transparent fake-door test. The purpose was to measure interest before building the payment flow.

The decision to stop

Then I found the real problem.

To use the product, people upload personal photographs. Those photographs could include children.

The privacy safeguards were not good enough. A disclaimer at the bottom of a page would not make them good enough.

So I stopped circulating the link.

The experiment had involved a very small number of people. I could have continued collecting feedback while the privacy work waited. I chose not to.

I put the issue at the top of the product backlog. This was a side project, not my full-time job, so the work did not happen the following day. But while it waited, the link did not continue travelling.

When I returned to the product, privacy came first. I added an initial set of safeguards before reopening the experiment: clearer information about storage, EU-based hosting, a deletion process and an explicit restriction on uploading photographs of minors without the required consent.

These measures reduce the immediate risk. They do not replace a full privacy review before wider distribution.

The first safeguards inside the product, where people encounter the decision rather than in a policy they may never read.

Stopping distribution was not separate from building the product. It was part of building it.

The honest timeline

The first version took four days because the deadline was real.

Everything after that happened in fragments, around other work and responsibilities. The commit history includes a stretch of fifty-six days with no development.

Those were not fifty-six days spent working on privacy. The project was sitting in the backlog and distribution remained paused. When development resumed, the privacy work came first.

Eighty-six days of commit history: the initial four-day sprint, the first product iterations, the pause and the return.

I prefer this timeline to a cleaner version of the story. It shows the difference between a focused product team and a side project. It also shows that speed is contextual. Four days can be enough to ship a first version. A backlog item can wait much longer when the project is not your first priority.

The relevant decision was not how quickly I returned. It was what I allowed to happen while the risk remained open.

What building changed

Claude Code shortened the distance between an idea and something a person could use.

That matters. I can now scope a small experience, build it, deploy it and put it in front of someone within days. I have a clearer sense of what current tools make cheap, what remains difficult and where technical choices affect the product.

But the experiment did not teach me that product leadership is now about writing code.

The hardest decisions were still product decisions:

• Is a positive reaction a useful signal or just politeness?
• What is the cheapest valid way to test willingness to pay?
• Which infrastructure is premature?
• When does collecting more feedback create an unjustified risk?
• What needs to be fixed before learning can continue?

AI changed the speed of execution. It did not make judgment less important. It made the consequences of judgment visible sooner.

So, am I technical enough?

I still do not know where that line is supposed to be.

I know that I can move from an idea to a working product without waiting for a team to make the idea tangible for me.

I also know that shipping is not the end of the work. Building means choosing what not to build, reading weak signals without inflating them, recognising when to stop and taking responsibility for what happens next.

“Product builder” is useful when it describes a practice. It becomes less useful when it is treated as a category that people either belong to or do not.

The better question is not whether someone deserves the label. It is how quickly they can put an idea in front of a person, what they learn from the response and what they do when the evidence changes the plan.

I shipped the first version in four days. I chose not to build a payment flow without evidence. I stopped distribution when I found a privacy risk. And when I returned to the backlog, I addressed that risk before restarting the experiment.

That is the part of building that matters to me.

Every date, number and decision in this article comes from the project’s commit history and backlog. The public experiment is available at wrapt-regalo.vercel.app/en. Nothing from the private version made for my daughter is shown or shared.