Sailing the Uncertainty Sea

I watched my teammate's face when the PM said it.

"Alright guys, our initiative didn't work out. Users aren't using the feature. Let's set it aside for now and try something else."

His expression. Well, he wasn't screaming. He just sat there and be quiet. But I could feel it. He spent three weeks building that feature. Good code. Clean architecture. Proper tests. I even reviewed his PRs. And now it's gone.

Later, he vented to me (I'm his manager). It wasn't about the pivot, it was more about his... feelings. And opinions. About whether they think about this initiative first before they decided on it. About whether they really made sure about this. About whether he was being led by the right person. I'm not going to write everything he said here (PMs might be reading this), but you get the idea.

It's not just him. I've heard many. My teammate from Boyolali. My engineer friend from Jember Utara. My he-think-he's-handsome friend from Ciwastra.

I get it. I do. But with one caveat. I don't feel the same thing. Because I love this stuff!

The projects no one knows how to do

I'm that guy they call when a project is completely unclear.

Fish appetite sensor. Detect when fish in a farm are full so we can automatically turn off the autofeeder. How does that work? No idea. How will customers use it? No idea. What should it even look like? No idea. The only idea they have is to call me to work on it.

Financing system for fish farms. Like any financing system, we have credit scoring. But this credit scoring is based on cultivation data, not normal surveys. Has anyone done this before? As far as we know, no. The whole business unit was figuring it out together as we built it. This time, I'm not alone.

The company's first data platform. I was the first data engineer. Build it from scratch. What should it do? What tools should we use? What problems are we solving? All unclear. Back to being alone again.

Oh no, this again. Oh no? Oh yes! Let's go!

Right now, I'm working on BukuCepat.id. It's an AI-based financial data input for businesses. We're building from a blank canvas. There's no PM. We're doing it ourselves. As engineers. Product engineers. Founder engineers. Me and Ans.

We decide everything. UI/UX design, go-to-market strategy, product analytics, customer conversations. We set our hypotheses. We expect them to be wrong. And when they're indeed wrong, oh no. Oh no? Oh yes! Very exciting!

That's the part I love. Being wrong means we learned something. It means we remove one thing that is "not", and get closer to what is "yes". We're basically doing Amerigo Vespucci. Amerigo didn't know which way America is. But he sailed. "Welp, that's not America, turn around matey we're not in the right way!" And then America there is. America!

But that's me. A lot of engineers hate this. They get frustrated. Anxious. Venty. Sometimes angry.

Why it hurts for them

I talked to my teammate who got this (subjectively) unfortunate news later.

"I built that feature properly," he said. "Clean code. Good architecture. Tested it thoroughly. And now it's gone. What was the point?"

He felt like his work was wasted. Three weeks of his life, deleted. Time he could have spent building something that would actually be used.

He was attached to what he built. He was proud of that code. It was HIS. Well-crafted. Now in recycle bin.

All of this is valid. I'm not saying he's wrong, but my brain just works differently.

What it's different for me

When our hypothesis doesn't turn out to be what we expected, I didn't feel loss. I feel progress.

I don't get attached to code. Code is just text. It's a tool. It's a means to an end, not an end itself. If it doesn't solve the problem, delete it and try something else. No emotional connection.

With BukuCepat.id, we've thrown away so many prototypes. Different UI approaches, different interaction models, different ways to prompt the AI. None of that bothers me. Each throwaway steer the ship to the right direction.

I see shutdowns as learning. When we learned that approach doesn't work, that's valuable! Now we know what NOT to do. We're closer to the answer.

Last month we built a feature we thought users would love. They didn't use it. At all. We killed it after a week. I was excited. We learned something about our users in a week instead of wasting months. Ship early, fail fast, learn faster.

I expect my hypothesis to be wrong. When I build something, I assume it might fail. That's may sound pessimistic, but it's actually not. The goal isn't to be right the first time. The goal is to learn fast!

We set hypotheses explicitly. "We think users will prefer X." Then we build it, ship it, and watch what happens. When we're wrong, that's a data point. That's result. Failures are still results.

I measure success differently. Not "how much code did I ship" but "how much did we learn." If a failed experiment taught us something, then that's a success. It's a failure only if we get nothing from it.

I'm comfortable not knowing. On the fish appetite sensor project, I had no idea what I was doing. That's normal for me. I just start building, see what happens, adjust. And actually, because no one was telling me what to do, or overconstraining me with their opinions, it was easier for me to work on that.

To be fair to my teammate

But! BUT. My teammate's frustration isn't always wrong.

Sometimes pivots DO happen because of poor planning. Sometimes we COULD have thought it through better. Sometimes the PM (or in our case, us engineers playing PM) really didn't do their homework.

It's easy to say "we're learning iteratively!" when really you're just throwing spaghetti at the wall because you didn't want to do the hard thinking upfront. That's just an excuse. Don't use "iterative" as an excuse!

There's a difference between:

• Good uncertainty: We don't know what users want, so we're experimenting to find out
• Bad uncertainty: We could have figured this out with basic research but we didn't bother

My teammate's pushback were maybe valid critique. "Did we even talk to users before building this?", "Did we re-check with their managers?", "Did we think about our next year plan?"

Those are good questions.

And on the PM side, if you're going to ask engineers to sail the sea of uncertainty and pivot frequently, you owe them something. You owe them the thinking you DID do. The research you DID complete. The clarity about what we're trying to learn.

Don't just throw ideas blindly at engineers and call it "iterative." Unprepared != iterative.

What I notice about myself

Maybe I'm just lucky. The ambiguity doesn't stress me out. I naturally love sailing the uncertainty sea. But that's not better. It's just different.

If you're someone who hates unclear projects, that's okay. You're not wrong. Find the projects that play to your strengths. Build things that matter. Take pride in quality. Push back when "iterative" feels like an excuse.

If you're someone who loves sailing the uncertainty sea, that's cool too. But remember, not everyone's built like you. Be patient. Communicate. And maybe, just maybe, sometimes your teammate is right that you should've thought it through more before building.

Well, you need to communicate and ask people first before you ask them to sail to America.