My hilariously simple mistake that wasted $144,000 in 3 Months

Smart people avoid doing what I did

In 2023, I stared at a tiled screen of confused developers on Zoom who looked at me like I'd just taken my pants off and told them to sculpt me out of clay.

An engineering manager had scheduled this call for me to share our progress with the broader team. Ten minutes in, my inbox pinged with DMs and low key panic from my team.

So how'd I get us into this mess?

After a few years at a large agricultural company—and yet another org change—I was asked to help shape the next generation of their flagship digital product. I was excited: real ownership, a fresh product management team, and the rare green light to build things differently. We were still scrambling to hire, but the leadership was on board. So although it was a hectic time, that chaos had its perks.

We did what any seasoned team would: We visualised messy ideas to test our thinking, mocked up flows to see what specialists thought was possible, and prototype just enough to learn—would farmers actually want this?

It seemed like the right approach. In our early check-ins, everyone was excited. Suddenly, our team was the golden child of moving quickly, an example of how leadership wanted others to work. I felt thorough, collaborative, and tuned into the sensitive, wonderful specifics of agriculture. We finally had breathing room to iterate and improve.

What could go wrong? Pretty much everything from day one.
I was being a dumb dumb, and ignored every red flag for three months.

The “Uh oh math” that hurts

Six people at $400 a day for three months (60 days). Meant my inaction cost us $144,000.

Mistake #1: "We'll Loop Him In Later"

The first obvious mistake happened before we even started. The engineering manager couldn't catch a flight to our initial meeting. Instead of being smart and rescheduling, we foolishly went ahead anyway, bringing together crop specialists, designers, and product management leadership to define our approach. We could "loop him in later."

Here’s why "we'll loop him in later" was like punching myself in the face:

Even though we all agreed he should be there, we still went ahead and fleshed out our thinking. If he'd been present, he would have quickly told us the current engineering team had extremely different expectations for how they'd work with us.

The team was new, and who we'd have access to were junior, execution-focused developers—the type who wanted to review and complete Jira tickets. Not the collaborative product engineers who would spar, iterate, and solve problems with us.
I can complain about "how people should work" but that don’t move you forward. The right approach isn't just about what's best—it's about what fits your team's capabilities and how the company actually works.

Mistake #2: Theory vs. Reality

My second self-inflicted punch to the face was learning that even though we were following the "right" process—keeping it lightweight and testing our way forward—the concepts we were evaluating were based on wrong information.

Sure, we were building a new product, but we were expected to use very specific APIs another division was developing. All those useful features we learned people wanted? Our team couldn't build them. Good learning, but it doesn't help THIS PROJECT move forward.

Again, the engineering manager would have known this on day one. Those API limitations weren't in the written documentation. The technology we were designing for literally didn't exist yet in the company and wouldn't for another year until research trials were further along.

There is a big difference between theory and having someone who works intimately with a topic everyday.

Mistake #3: When Everyone Just Keeps Nodding

We didn't just go on a designer rampage for three months. We tested concepts, got feedback, shared what we learned with different teams, and every two weeks presented progress.

Which brought about other red flags I should have paid attention to. We weren't getting any pushback or real comments. We were following a process, checking boxes, and people would nod along.

Here's what I learned about meeting dynamics:

Group size matters. If you have more than five people, don't expect anyone to give you critical feedback. After six people, the group moves into observer mode—glazing over details and just following the conversation.

Meeting fatigue kills feedback. If everyone you need feedback from is in meeting marathons each day, your large group call becomes their break. They clock out and their brain snoozes.

If you're hearing "I've gotta jump to my next call" regularly, it's likely you don't have their focus.

A smarter person would have stopped at each of these red flags

• 🚩First, the engineering manager couldn't make our kickoff — "we'll catch up next week".

• 🚩 Next, defining our target customer would come later — right now we need to design for all use cases.

• 🚩 Then, a developer mentioned preferring detailed specs, and I said “Well we can figure that out as we go together”.

• 🚩 Finally, In technical reviews we’d hear "let's park that for now", until we could show more of the product.

Because I dismissed these early warning signs as minor details we'd sort out later, we spent 3 months working and testing with the wrong constraints.
At a conservative $400 per day per person, Every "we'll look at that next week" was costing us $2,400 a day – All the while I confidently walked us further and further in the wrong direction.

Ten minutes into sharing our progress with the engineering team to "make sure we're all on the same page"—again, after weeks of reviews and check-ins—these confused faces told me we weren't even reading the same book. I had officially wasted $144,000 on my team alone by not getting the right people on the same page from day one.

My small dismissals compounded into expensive problems. The "we'll look at that next week" can become an expensive decision that buries you.

Let’s finish here.

When we build something new, we evaluate it in three categories:

1. Is it desirable? Will people want this if we make it?

2. Is it viable? If we make this, is it worth our time as a business or society to invest in doing this?

3. Is it feasible? Can you build this? Not just can it be built, but with the constraints your team has—can you actually build this?

The first two went great. The third? Not so much. I was 100% confident that what we were shaping could definitely be built. But not by the current team, within their constraints. You have to play the course you're on, because you don't get points for trying—only for making something people actually want.

What I'd Do Differently

If I could do this project again, I'd bring the core five people from the leadership team together first. We'd define our core hypothesis, why a customer would care, and how we'd approach moving forward. So even if we were wrong, at least we'd all be wrong together. Then we'd find problems and adapt as one team. No confused camps.

—--

I send this email weekly. If you would also like to receive it, join 160 other smart people who absolutely love it today.

👉 If you enjoy reading this post, feel free to share it with friends! Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏