Here’s a big mistake we made at my previous company: we never really dogfooded.

Dogfooding, from the phrase “eat your own dogfood,” simply means to “make sure you’re using your own products.”

It’s obviously “important”, a best practice even. After all, who has better feedback about a product than the people making it?

In real life, you get two problems: first, how do you rank your own priorities from dogfooding compared to the stuff actual customers want? And second, what if your product doesn’t quite fit your use case? Do you change it to fit better?

In other words: how important of a customer are you, for your own product?

Back in the day, we were under severe pressure to cater to customers. We were scrambling to close every deal we possibly could, so we could survive. Our product was still in its infancy, and every customer found gaps. Our roadmap filled up with commitments and critical issues to solve. Dogfooding came in as a very low priority. Yes, our product didn’t quite work for us, but it didn’t work for paying customers either. Our priorities, we thought, were clear.

Later on, when prospects came in, we were able to determine whether our product would be a good technical fit for them. We would green-light deals that seemed to mostly work, and pass on the ones that didn’t.

Ironically, our own company was not a good fit for our product. Not because of business or product reasons, but because of pesky technical challenges. We could definitely solve some of the issues and properly dogfood, but, alas, it was always a low priority. How do you justify working on the dogfooding pet project when so many customers are starving for R&D attention?

Over time the situation grew to be absurd. We made demo software, but we didn’t use our own software for doing demos. We would wax rhapsodic about demo tools, while screen sharing a demo in the most primitive way possible. I’m not sure how many deals were lost to this dissonance, but it did become a bit of an inside joke. Unfortunately, we were the butt of that joke.

I’m certain that if we decided to hunker down and commit to dogfooding, the benefits would have been immense. Yes, a deal (or a quarter) might have been sacrificing, but we would have come out much stronger on the other side.

Every challenge would have been a perfect practice run for real customers. And we would be the ideal customer: We’d be the earliest of early adopters; We’d be willing to try anything to make our product work. Sitting in the same office, we’d accomplish in days what would take weeks or months with anyone else.

Hindsight being 20:20, this could have been a pivotal moment for us, but sadly it was an opportunity we chose multiple times not to take.

My final words of advice: don’t let everyday roadmap pressures get in the way of proper dogfooding. The benefits of short-circuiting the R&D-customer feedback loop can be tremendous. You can literally save months and make far fewer mistakes. It’s worth it.

So here’s an important lesson from my previous company: keep your team as small as possible until you reach product market fit.

First there’s the obvious reason: smaller team means less burn. Less burn means you have more time to iterate.

Second reason: more people require more coordination. This means more tools, more processes, more opinions and feelings, more discussions, and more time lost. What you gain in extra throughput you lose in extra latency. Early on you need to react fast to feedback and not take months to make changes.

Little parable from a friend of mine: ordering pizza for 4 people is much easier than ordering for 20. You got 20 people, you have to have a spreadsheet. You have to collect money, deal with allergies. Not every place can do a 10 pizza order, so you have to order ahead of time, etc. Four people is simple — single order, no fuss, you’re done.

My favorite corollary: ”if you need JIRA and Salesforce before you have 10 happy customers, you’re doing something wrong.”

Third reason: smaller team means you rely on trust and on gut feelings. Wait is that good? Shouldn’t you try and gather as much data as possible before you make moves? I don’t think so. Early on there is no data. Nobody knows what direction to go in. You have to make educated guesses, which means you need to have good taste. More people means committees and a more diluted vision.

If you’re a founder, try to keep your team small. Do less things but do them really well. Find a customer and become obsessed with making them happy. When you can do that reliably, go ahead and scale.

A product, just like a person, has a soul.

Just like a person, it has opinions. It has its ideas and ideals. It has a viewpoint about the world it’s in. It has its quirks, its idiosyncrasies. It has things it’s brilliant about and things about it that are frustrating. Things that it is fastidious about and things it shrugs off as unimportant. It can aim to please or it can be obtuse. It has a memory of the past. It has hopes and an outlook about the future.

A product leader’s job is to hold, maintain, evolve and communicate about the product’s soul. To recognize feedback about it, to interpret it and to talk about it all the time.

When you build a product team, find people that understand this and that love getting to know a product intimately, make decisions that are coherent with its worldview, and of course, help develop it into new directions.

When you make a decision based on what makes sense for the product’s soul, make sure to put it in words. It’s important that the team is comfortable discussing things at this level. Talking just about data and user stories will only get you part of the picture.

And don’t limit this to just your product team. Talk about it with everyone. Make it part of your roadmap, your all-hands meetings, your presentations, your documentation even. Mention it in a panel. Everyone should know about it. The more micro decisions made that take it into consideration, the better.

When you see someone make a good decision, make sure to tell them, and tell them why you’re proud. Ask them about what made them do it that way. Make a point of it to others.

When you give feedback, drill deeply and explain, specifically, what you don’t like and why. If it’s a gut feeling, say so and try to word it in a way that they understand. If you disagree, make sure they at least have all the information.

You can ask why bother with this whole “soul” business? Do customers notice it? Can you build a great company without it? What’s the upside? The downside? Is there even a way to measure it at all?

My answer is that it’s not a rational thing. Not sure there’s any solid data for or against it. It’s a feelings thing. Emotional. You either get it or you don’t. But I can tell you that if you do get it, and you work with a team that gets it too, there’s really no going back from that. It’s so rewarding that I can’t imagine managing a product any other way.

Good communication is the difference between regular old mail and DHL:

1. I always know what’s going on,
2. I get listened to when I have questions,
3. I get answers to those questions, and
4. If I have a problem, they honestly try to fix it.

That builds trust and that trust is why I’m always happy to use them and pay a premium on top.

Even if the end results were the same (e.g. delivery was just as fast) I would still pay for and appreciate them, because just them being communicative and trustworthy reduces stress in my life.

Same principle applies to colleagues: I’d rather work with a great performer who’s also an excellent communicator, than with a stellar performer who’s a lousy communicator.

Ask me about the key to success, and I’ll point to luck. It’s not something many like to admit, especially those who pride themselves on being self-made. But the truth is, a lot of things have to go right that are completely out of our control. Your investor staying on, good weather for crops, stable personal lives, a competitor’s missed opportunity—these are all strokes of luck that pave the way to success.

But luck only gets you so far. What really matters is making good decisions. Opportunities might land in your lap, but you have to know what to do with them. Life is full of tough calls, and how you choose can make the difference between success and failure.

Making choices, especially the right ones, comes with experience. It involves learning from your mistakes and being smart enough to apply those lessons in the future. It’s about developing a method to navigate through those tough decisions.

Take, for example, the dilemma of a chef who dreams of owning a Michelin star restaurant but starts with a simple cafe that becomes unexpectedly popular. This success, though not what was originally envisioned, presents a crossroads: stick to the original dream against the odds, or pivot and build on the unexpected success.

This scenario isn’t unique to startups. It’s a common crossroads in any significant project or endeavor. When things don’t go as planned, do you keep pushing your original vision, or do you adapt based on what you’ve learned?

It’s a tough choice. There are stories of success on both sides—those who persevered with their original vision against all odds, and those who adapted and thrived. Knowing which path to take can be difficult.

Personally, I tend to lean towards flexibility, adapting to new information and ideas, even if it means giving up on an initial plan too soon. To balance this, I surround myself with people who are more stubborn and persistent than I am. They help me stick with things when necessary, or I can convince them to pivot when they see the wisdom in it.

Next time you’re faced with a good but unexpected situation, think about whether to resist or embrace it. The right choice could make all the difference. And, of course, it never hurts to be lucky.

When you’re running a startup, especially during tough times, everyone talks about “strategy”—how crucial it is, how confusing it can be, and the problems with a bad one. Having been in these discussions myself multiple times, I wanted to break down some painful lessons I’ve learned.

Painful Lesson #1: A strategy isn’t just a list of goals

Strategy is not about setting goals. Setting goals is important, agreeing on them is crucial. But it’s not a strategy. A strategy is not your goals: it is the blueprint for achieving them. It’s the how, not the what. Your goal might be to release a killer product, to elevate sales figures, or to reduce customer churn. However, there are many possible paths to these destinations. To use a navigation analogy, if your goal is a landmark in the horizon, your strategy is the chosen route and plan to get to it. So yes, set goals and measure your progress towards them, but you need to decide and agree on how you want to get there as well.

Painful Lesson #2: Why even bother?

Why bother with a strategy? Don’t you feel you kind of know what needs to be done? Why can’t we all work towards our goals and see what works the best? The problem with this approach is that it is a waste of time and energy. Divergent ideas and methods lead to conflicts and dilution of focus. It’s like cooking a complex dish without a recipe, where each chef adds their own ingredients, ending up with a dish that’s a confusing mix of flavors and techniques. You have a bunch of talented people, but will end up with a muddy mess.

Consider this: You aim to boost phone sales. Do you create a high-end model for enthusiasts or a budget-friendly option that will sell better, but with lower margins? Well, both could be a good way to increase sales, so do one or the other. But without a coherent strategy, you’ll be doing both at the same time. These approaches will clash, vying for resources and attention. Teams will fight with each other, arguments will ensue, and confusion, frustration and compromise will follow. A well-defined strategy will serve as a guiding light - helping you make all the micro-decisions without constantly questioning the logic behind them. Of course, strategies aren’t set in stone; they should evolve with data and changing landscapes. If your phone isn’t selling, it’s okay to make a different phone.

Painful Lesson #3: What makes a strategy good?

Forget about looking at a strategy and trying to guage if it “will work”. Predicting success reliably is like trying to forecast the weather in a month: nobody really knows. Nonetheless, a promising strategy tends to have some early indicators:

1. Simplicity: Can you explain your strategy in simple terms? Complexity breeds fragility and risk of failure. If it’s hard to understand it’ll be even harder to follow.

2. Robustness: Does your strategy stem from solid data or core beliefs? Without this foundation, wavering is inevitable.

3. Clarity: A good strategy acts like a light switch in a dark room. It brings sharp focus, helping you decide which projects to axe, where to allocate resources, and which features to prioritize or discard. Recognizing past mistakes is a byproduct of a clear strategy, enabling you to avoid them in the future. If your strategy doesn’t help you quickly cut away all the mistakes you’re making, it’s probably not sharp enough.

Painful Lesson #4: The concept of Anti-Strategy

A few years ago I read this excellent post on anti-values. The gist is that anyone can come up with company values that sound great on paper, but the real challenge is what you’re willing to give up to truly live by those values. Example: move fast and break things: go fast, even if it means making costly mistakes.

I find the notion of an “anti-strategy” equally vital. It’s easy to articulate what your plan is, but what are you willing to sacrifice? This might mean prioritizing enterprise clients, even at the expense of losing small and medium businesses. When push comes to shove, will you be willing to let a small customer go, and lose that revenue?

An anti-strategy involves premeditating the tough calls you’ll need to make. Without this foresight, you’re unprepared for sacrifice. And without sacrifice, you’re likely to end up with a tepid, ‘design-by-committee’ approach that seldom succeeds. Just as no decent restaurant tries to serve every cuisine, no successful business can excel at everything. Pick one thing and do it extremely well.

•••

In conclusion, strategy in business is more than a buzzword or a set of goals. It’s the art of navigating the complex and often unpredictable waters of the market. It demands clarity, simplicity, and robustness. Equally important is understanding what you’re willing to sacrifice—your anti-strategy. It’s hard and often emotional work to articulate it, and often even harder work to act upon it. But without it, you’ll be lost.

A few months ago I was at the drawing board with our product team. We were sketching out what the roadmap for the next few months will look like. I asked about a feature I was keenly awaiting — a new metric for our analytics dashboard.

I was told that building it could be done in a few days, but there was a catch. The dashboard itself is starting to feel like a crowded subway at rush hour—it needs a redesign.

Suddenly, a voice piped up: “We shouldn’t bother building the new metric for the old dashboard. Why don’t we wait for the redesign and then launch that and the metric together?”

On the surface, it sparkled with efficiency. Why embed a new metric into an aging design, only to revamp the whole page later, metric included? Woudln’t it be wiser to do it all in one fell swoop?

However, I was leaning towards a “no”. How come? Because this path, as alluring as it seems, is often a rookie mistake. Let’s delve into why.

A bundle of troubles

Bundling tasks together is like Frasier and Niles planning a dinner party: it starts out simple enough but can quickly spiral out of control. Adding the metric might be a quick fix, a matter of days. The redesign, though, is a longer journey, perhaps a month. Bundle them together, and the metric’s debut is suddenly a month away, not days. You’re now faced with explaining to your audience and higher-ups why this ‘simple’ metric we promised is taking so long to deliver.

Bigger projects also translate into more risk. Amidst the redesign, you could stumble into a maze of challenges: unresolved product questions, data migration issues, documentation, new components needing birth and nurture, lengthy QA cycles, and more. Each detour pushes your shiny new metric further and further down the calendar.

This phenomenon has a name in tech lore: Yak Shaving. You set out to build a feature, and a month later, you find your team knee-deep in seemingly unrelated tasks.

Embarking on the bundle journey is like boarding an express train — you’re on it for the long haul and it’s often impossible to get out. The design and code of both features become entwined, inseparable. Deciding to uncouple them later? That might require a golden fleece of its own.

In the startup arena, where I spent most of my career, rapid iteration is your secret weapon—your only weapon, really. It’s what sets you apart in the league, your ability to dart and dash. While you’re tied up in the bundle, you miss out on vital feedback loops. When you eventually release the metric, you might find that nobody cares. Worse, your entire dashboard might be greeted with yawns. By bundling, you’re blindfolding yourself to these critical insights for precious weeks.

Data > efficiency

Releasing the metric first, then marinating in the redesign phase with a richer dataset, is akin to building with a blueprint rather than a hunch. Yes, it may take longer overall, and you may end up rebuilding pieces you’ve just recently introduced, but that month of user feedback is worth its weight in gold.

Is it ever prudent to bundle? Maybe, particularly if one element serves as a foundation for the other. Yet, take a moment to reflect: Is bundling truly inescapable? Now, entertain a different strategy: what if we flip the script? Initiate with the redesign, gather insights from this phase, and then, with a more informed perspective, roll out the metric (or even do something else). This approach could still be slow, but will offer a richer tapestry of data to inform our next steps.

In sum, sidestep the bundle temptation. Embrace incremental, iterative releases. Prioritize data and feedback—they’re the compass and map for your journey. Better to tread cautiously on the right path than sprint down a winding road leading nowhere.