I have worked in GTM/PM consultancy for some time now. This is the patterns I often observe:

  - Have a vague understanding of the problem
  - Architect an overcomplicated solution thinking of all possible contingencies
  - Pitching the overcomplicated solution to someone else
  - Ask them to come up with a simple solution. Ask questions to "birth" to the solution.
  - Not providing any feedback as that would mean need you to be accountable for the work
  - Trying to convince them they should work out the solution because they are the expert and much smarter then you
  - Taking credit for solving the problem

This seems strongly aligned with the Amazon doc-writing and decision making process. I found it to be unusually effective as a business process, and took it with me when I left to my current role.

Making thoroughly informed decisions and iterating on a decision doc before committing to a direction and plan is better than every alternative I’ve ever observed in my career.

The criticism I’ve read thus far on this thread seems unwarranted. I give the same kind of feedback to my mentees when their work product or process could use improvement.

> 3. Define the problem

If you do this step well, in my experience, the next steps fall into place quickly.

My version: accurately naming the problem is the essence of problem solving. There are things you usually need to do before you can accurately name the problem, because most problems aren’t presented to you in textbook form.

Once properly defined and framed, it’s obvious how to solve most problems, most of the time.

If you’ve ever worked with someone amazingly good at accurately naming the problem, it’s hard to unsee it. This is one of the hidden talents of the most effective people I’ve met.

I am confused by step 5.

A. Why define the goal after identifying the solution? Or does define the goal mean identify a stopping point for step 4, in which case you must first define the solution?

B. Isn't the goal explicit in a clear problem definition?

1) Ambiguous problem definition with no implied goal: We need more money.

2) Clearer problem definition with implied goal: We need $500K by Monday.

It’s often struck me how many “leaders” basically jump to step 6, and come up with an urgent set of superficial actions without even clarifying what they’re trying to do. There’s probably some value in “bias for action” as you might call it. But it’s been one of the difficult adjustments for me, how little people want to think.

Steps 1–5 of his framework are increasingly formal ways of saying “figure out what’s going on before doing something,” followed by step 6: “then do it fast”

Haven't seen any Claude Code specific examples of Boris admitting he's wrong and then actually fixing things in the way the community wants.

There are mind blowing bugs in CC that go unaddressed for months.

Something like 15-20% of all Fable messages in CC are invisible to users. You've most likely noticed this when Claude references something it said but it never said it?

It happens frequently when Fable outputs a message above a certain number of tokens just before doing a tool call.

This has been going on for months. If "users can't see messages the agent sends" isn't a critical issue that gets addressed within 24 hours, I don't really care if you admit you're often wrong, we know.

Boris's checklist is just a slightly modified version of your classic mathematics or engineering problem solving steps.

1. Write down your problem statement.

2. State your knowns, unknowns, and assumptions.

3. Solve.

(Step 2 is also further enhanced by performing first principles reasoning, collecting data for evidence, and using reasonable estimates where data is absent.)

I think Boris's list is pretty solid, but I personally would unmix the problem solving methodology from the planning/goal setting SMART principles as two separate things. One addresses problem solving, while the other addresses human cognitive shortcomings for getting things done.

That's what it took to finally support Agents.md I guess. Boris had to blog about having made a mistake.

How about you stop taking things so personal instead and let others steer more.

I find myself slightly more hypothesis-driven, so I tend to be more effective putting much of the focus of 2. Gather missing information after 3. Define the problem ... or at least inside the iteration loop.

As others here have noted, it’s very easy to get lost gathering information that isn’t actually helpful in assessing whether the problem is well formed or whether potential solutions are applicable.

The more you force yourself to specify the problem clearly, but treat your initial problem definition as somewhat suspect - potentially missing key dimensions - the more you will be comfortable finding the information to validate / challenge it (or it's implied solutions) and re-shaping both the problem and it's solutions efficiently.

Unlike me, 56 and yet to be wrong once.

This post has the same vibe as the best/worst of modern tech leadership principals. I feel these things are like a rorschach test for an individuals current position corporate psychopathy scale.

There are times in my life where I'd have read these, been really deeply impacted by them, and picked up a new mantra or 2 for a few weeks. It's like "Get a plan, execute it violently, do it today".

If you're in a time and place where you're motivated to "move fast and break things", I think you'll nod along with Boris' post.

But it's so general and high level, the only meaning you get from it depends entirely on your own personal attitude and examples that you throw at it.

The obvious pro angle is: "yeah, understand stuff well, biased for action, act urgently, yeah!" and competent, motivated, currently-in-the-zone people will spring into action. (But they would have done anyway, because they're already motivated and in the zone).

The obvious against angle is "uuuh, last week you said we needed to be goal oriented, and now you're telling us to go and learn a bunch before we even know why/what we're learning? And I've learnt a bunch of stuff, but you're telling me it's not right because it doesn't fit within this framework you just invented that you're now telling me I absolutely have to follow and you're my manager so I have no choice?"

I'm not totally hating on this, there's a time and a place for it and I've found it very motivating at times where I was already thoroughly motivated, but I think it's also useful to recognise that it comes across as self-serving platitudes for a lot of people who aren't already in that kinda zone.

It seems strange to write a blog post about being proven wrong, without a single example of being wrong. Especially with all the current Claude.md drama.

Everyone loves being wrong in the abstract - this reads more like a self-congratulation than a genuine reflection.

> Something that people learn quickly when they work with me is that my approach to pretty much every problem is: > ... > 6. Act with urgency to achieve the goal

If everything is urgent, then nothing is. This guy sounds miserable to work for and with. Assuming this is accurate and not just hyperbole, he is essentially saying he has no prioritization skills because everything is urgent. I think most people who have been around the block have worked with people like this, and unbeknownst to them, their coworkers develop a default snooze button associated with most of their requests and projects.

I like Boris's list, if only because it's obvious. Anyone responsible for solving a problem goes through these steps, either pro-actively or re-actively.

Organizations usually suck at this part. Being time & resource constrained, the focus on anything but actual problem solving is just staggering to me. I haven't worked at every place, so your mileage may vary.

Nothing more annoying than a manager with a personal know-it-all framework requiring people to follow it or else they get "feedback".

I can't say I agree with forcing your team to use your own personal "framework" of approaching a problem or else you'll get "feedback".

> Sometimes I will give feedback to people when they are missing steps in the framework, or are poorly executing some of the steps. I expect the same feedback in return.

I also don't like that urgency is built in as the standard process either, no wonder everyone is burnt out.

> 6. Act with urgency to achieve the goal

> I hope it is interesting or helpful

I think you're wrong. I think it's embarrassing. Though I might be wrong.

I absolutely love it, and this correlates perfectly with Polya's math problem solving [1] combined with Fail Fast [2] .

[1] https://en.wikipedia.org/wiki/How_to_Solve_It

[2] https://en.wikipedia.org/wiki/Fail_fast_(business)

It is strange how people who say they are "often wrong", never quite sound like they take that into consideration when delivering opinions or thought pieces - I see it fairly often in tech. Anyways; nothing against Boris, but Anthropic/Claude has certainly been the first company (& product) too annoying for me to use.

This guy doesn't think deeply about any problem, possibly because he has never had to and probably because he has never wanted to. He would probably make a good residential plumber.

Right and wrong are forms of judgement, subject to debate, and sources of resentment.

Correct and incorrect are at least possibly quantifiable and do not intrinsically involve subjectivity.

In other words, my being incorrect is something others can help me to understand and rectify. My being "wrong" is a position which can yield second order harm.

It’s sad to see how these insights and “drops of wisdom” have changed to the point where nothing substantial seems to come from people who are in a position to influence, at least to some extent, the software landscape and where the industry is heading in terms of practices and approaches. Instead, we get shallow, very basic principles, still valuable, but often little more than mid-level-engineer realizations being spat out.

The worst part is that the product, the actual output, often feels underwhelming and at odds with the narrative around it. Action matters more than the narrative. Show these principles in your work and in how you engage with the community, rather than through shallow thought-leadership mumbo jumbo.

Another thing I find skin-crawling is bragging disguised as humility and sincerity. Come on!! Expecting people to buy into that performance is, in itself, a kind of insult to their intelligence.

[flagged]

Having listened to him give a couple of talks I am always struck by how much he talks and writes like Claude code.

I don’t think he farms out all of his writing and talking to LLMs. I don’t think Claude code was trained to emulate him or anything.

I think his “voice” has been filed LLM smooth by years of agent based interactions. He claims Anthropic engineers use an average of 500+ agents a day. They are human interfaces to token generators more than human to human communication. They are picking up the tendencies of their most frequent communication partner.

Unfortunately, I see Claude being wrong often enough that I view it as a faulty narrator. Often helpful, sometimes totally full of it.

And now I subconsciously apply this filter to anything that sounds like Claude.

Makes me nervous that my voice may be becoming that of a faulty narrators.

a foolish consistency is the hobgoblin of little minds

Title is click-bait with poor framing (i.e. if you are often wrong, then sometimes, you will be right).

Finishing your goals does not "make you right". Life is not a binary where you are either wrong, or right. Thinking that you ever become "right" or that you ever achieve 100% confidence that you have arrived at a "solution" is arrogance of the highest order.

Life is about getting better. Every person, every product, starts at a beginning. A beginning is not "wrong", it is early. We try, individually and collectively, to improve ourselves and that which we are responsible for. The decision to ship is not whether we have made something "right" but about whether we have made it better. We ship, knowing we will ship another improvement after this one.

> 2. Gather missing information... 6. Achieve the goal

Sometimes in life, you need to ship first in order to gather missing information later. You cannot do that if everything has to be "right" before you ship it.

> I love being wrong

This is not the essay of someone who loves being wrong. This is the essay of someone who loves becoming right. But the deeper truth is that you will always be "wrong" - unfinished, lacking knowledge, under-developed, incomplete. Do not love being wrong - love improvement.

And yet there's none of this uncertainty or caution with his posts that then go on to have massive ripple effects because of his position at Anthropic and the marketting related to claude.

I personally have a lot of anger and frustration with many people in the ai hypesphere that are just mindlessly frolicking around without a care in the world, happy to speak into the megaphone offered by masses that are in a rat-race to avoid some AI dystopian hellscape that keep getting painted by these thought leaders... and then going "oopsies... I am just human guys... y so mad?!"

> I love being wrong

I prefer being right, but to each their own.

“I am often wrong” is directly from how to make friends and influence people.

i am pretty sure it would just be "wrong," not "meta-wrong," and given the title, i am giving myself the point.

Wow. Is that the whispering earring story playing out in real life? I'd cringe if I'd found platitudes like that in my notes from the teenage days. Let alone flaunt it in front of the whole world.

Can't wait to hear about this brand new approach from my managers and VP.

We all have a short time on this planet. This desire to always have urgency, speed, more money is insane.

Humans are in trouble

so is coding solved or no?

Well maybe stop posting then and leave it to people who are not often wrong.

Boy, Boris, you're getting ripped on this.

Tbh your article is pretty poor. Your "framework" is what everyone on this planet does every day.

I guess the lesson for you is to realize that your wisdom nugget may annoy the shit out of your team.

I, I, I, I, I, I, I, Me me me me me me

This is what happens when you let things get to your head. You work on a (highly inefficient, often broken) piece of extremely basic software by prompting a slot machine and hoping it works. Calm down and stop forcing your shitty framework on employees, you're the most replaceable cog of all.

What LinkedIn post did this blow in from?

All 6 steps are wrong.

Goal definition is way down at step 5. Why do you even care about doing something even before you know the goal?

Why does step 6 has word "urgency" in it, as if it applies to all goals?

Getting more fundamental, why do you need to go through any of this at all? What happens if you don't do all of this? What's the cost-benefit analysis of doing all this and not doing?

undefined

I still am mind blown at how bad CC is as software. It’s just not that hard of a problem. I get that harnesses aren’t trivial, but they’re not insane either. And the fact that it’s running on a JS runtime (that they bought!) is also crazy. Why not Go/BubbleTea? Why not literally anything native? It makes no sense

I don’t want to be a jackass, but it’s hard to take anything Boris says seriously when he’s headed up such weird software. And it’s not like resourcing or money is an issue for them. If Claude was so damn good, why does CC suck?

Well, sounds like problems and products are largely solved.

60% of the time, the framework works, every time.

I think someone can follow "good practices" with a team and get to a bad place, especially with such a novel product (as AI coding agents).

But taking Claude Code as the product of this style of thinking -- who is Claude Code for? Is it for everyone in the world? Well, if you look at the feature velocity, it seems like the answer is intended to be yes ... Claude Code is trying to solve every problem in software development in the world, all at the same time.

So I question the "user model" here.

Here's another thing that is true about Claude Code: it's among the most inconsistent and buggy pieces of software I've ever encountered.

- You can move the cursor with the mouse in the composer, but not in AskUserQuestion?

- When agents spawn subagents, the model name is inherited from the main agent, and seemingly none of the (4! yes, 4!) subagent tools seem to get this right (except for Explore, which seems to be fixed to a weaker model)

- Sometimes, when my usage limit halts, my agents will pick up when it refreshes (within ~2 hours or something) ... other times, nope -- even within the usage limit?

This is a sampling of my own experiences using this thing frequently. Are these sorts of details not important? Maybe not: I'm not at the level of this team, and may never be.

But I think it's a reflection of agentic engineering ... a somewhat embarrassing one, from my perspective. It paints a picture of a team who can't quite get the details right, even with the assistance of purported extremely powerful AI tools, even internal ones which we don't have access to?

I think when people look back on 2025 -- Boris is going to have his name right there in the books ... Claude Code, coding agents -- Anthropic (& Boris + team) made the first move.

But now it's 2026, and people know how harnesses work, and heavy lies the crown.

Bayes spotted in the wild.

Heaps of comments here but nobody has pointed out he defined the goal after defining the problem. That's cheating.

Step one is to define the goal. Then you work out how to reach the goal. (Gather information and form a hypothesis) Then you take steps toward the goal. (Test your hypothesis to make sure you stepped in the right direction.)

Aka. business-as-usual being human.

I'm not sure how this relates to "building a product in the age of AI" or being wrong at all, this is just a list of steps that an elementary school student would be taught when learning how to approach any reasonably complex problem.

Imagine it were so simple that we had not figured out 1-6 before in all of our research and management principles over the centuries?

Like as though it needs to be stated?

I mean ...

There's a very weird thing they like to do in Silicon Valley where they re-invent everything 'in other words' - this time, no fancy words.

Also, I would say he missed the 'iteration and experimentation part'.

If $400K/yer people need this level of guidance, something is wrong.

This whole things feels kind of wrong.

Imagine it were just some random Engineer, what would we think?

Imagine if a non-tech person wrote this.

7. Reflect on that goal?

Translation: "I'm so wise guys, that I'm using epistemic humility principles to hide it"

why does boris have this urge to become an influencer

Just retire at this point, you don't even have to work.

The most annoying thing about this is that the steps are out of order unless the definition of problems and goals are intermixed 1. define a goal 2. understand information and gaps in information 3. define and prioritize the problems to achieve that goal 4. identify potential solutions for top problems and prioritize 5. measure success

and do all of it with urgency (magically managers want everything done with urgency)

you can only admit to being wrong if you are unfirable up in the hierarchy.

rest of us get fired if we ever admit at work that we were 'often' wrong.

Aha, another iterative improvement variant. (see also eg OODA and PDCA)

I'd argue that Boris Cherny is in fact nearly always wrong;

except when he's right, which is in the final pass just before the work is done. ;)

sorry, but when you reach certain levels of influence, you need to slow down, be more methodical, and not be so flippant

This misses the problem that your problem might not even be a problem in the first place and you shouldn't even be working on that in the first place. I'd recommend looking into Elon Musk's ethos which first focuses on finding what is actually needed and what actually needs to be done before going in and solving problems.

Yeah? A very basic process, most people use some variation of this implicitly without talking about it.

This sounds like a slightly narcissistic manager who thinks people are doing it wrong if they don't act like small copies of him. There are multiple ways to reach the same outcome and a lot depends on your information. E.g. I typically have a mental model of a system in my head, meaning when some problem needs fixing very likely I already know where it would need fixing and already think about the various future implications arising from a different fix. A point that is totally absent from that framework.

Being a senior dev myself I have seen enough good software turn bad to know that seemingly innocent technological decisions can come with huge and lasting implications. The fact that this is missing here is speaking volumes about the lack of experience at display here.

Your task as a manager isn't to create small copies of yourself. Your task is to know each persons weaknesses and strengths and compose the work in such chunks that the weaknesses have little effect, while the strengths multiply. For this you will first of all have to trust your people and lead them to discover certain ideas themselves.

E.g. if you feel someone always jumps gun-ho I to the task without doing the research, just tell them to give you the research first. Do that a few times and they might realize how useful that is.

quick - someone turn this into agentic harness :)

nice

Is there anyone else like me who can't help but noticed the url has a comma in it?

  /management,/product/2026/09/19/I-am-often-wrong.html

Removing that comma, you got a 404 error.

My pet peeve.

[flagged]

[dead]

[flagged]

[dead]

undefined

[dead]

undefined

[dead]

Boris is a scientist, that's all that has to be said here. Keep up the great work.

Heh, I have the opposite... uh "problem".

I am often right.

This has two negative effects;

1) I start to believe my own hype because I am so consistently correct- which blinds me to other ideas if I don't actively take steps to humble myself.

(after all, I won't be right very often if I stop listening, as that's part of why I am right, because I listen to people and have a huge amount of context)

and

2) I am able to quickly come to a conclusion which makes people uneasy, as they think I haven't considered all the points even though I have- and it's also true that people have a bias to inaction unless it's an urgent issue.. this is how things get stuck in committees and meetings and continually get kicked down the road because it's difficult to get everyone together and there's a million reasons to keep deferring meetings.

What I'm trying to say is, don't sit there thinking that "if only I could make correct decisions"- because even if you are quick, correct and decisive: you will ruffle feathers.

(at the risk of sounding arrogant: i'm not saying I'm right about everything, like the red baron, I pick my battles very carefully).