Treat AI as a Coworker, Not a Feature: The One Question Behind Five Decisions | CEO Insights

Treat AI as a coworker, not a feature. It’s a test, not a slogan.

Being “colleague-pilled” is a test for building and adopting products: whenever you’re torn on a decision, ask, “If this were a human coworker, what would I want them to do?” It matters because an AI coworker’s real edge isn’t how many features you bolt on. It’s whether you have one test that keeps hundreds of micro-decisions pointing in the same direction. Below, I use five decisions from Grok Bot to show what this means for B2B companies and manufacturers.

Contents

1. Shipping at light speed isn’t the point. Saying “no” is.
2. “Shipping your org chart” is the most expensive mistake
3. Colleague-pilled: one question that settles five debates
4. What it means for B2B and manufacturing in Taiwan
5. FAQ

---

Shipping at light speed isn’t the point. Saying “no” is.

What’s kept me thinking lately isn’t another model breaking another benchmark. It’s one team’s rhythm.

Grok Bot went from its first line of code to an internal prototype in about a month. Then came three weeks of internal testing, followed by a public beta. Zero to public in roughly seven weeks, and on the day of the recording the product was still in testing. That pace does take your breath away.

But I’d argue speed is the result, not the cause. What’s truly rare is what this team was willing not to build.

Roman Ugarte, who spoke for the team, was employee No. 15 at Cursor and watched the company grow from 15 people to more than a thousand. On paper, Cursor had everything it needed to stretch into general knowledge work: users were already using it for non-coding tasks, and the infrastructure for cloud agents was already in place. Following that path would have been the easy route.

They didn’t take it. That’s what made me want to write this piece. In this wave of AI, the most expensive thing is often not what you build, but what you hold yourself back from building.

Speed is the result. Trade-offs are the cause.

---

“Shipping your org chart” is the most expensive mistake

The team decided not to build the new product into Cursor, for three reasons. Coding tools intimidate non-technical users; the interface alone keeps people out. And Cursor can’t shake its brand association: to non-engineering colleagues, it’s “an engineer’s thing.”

But the reason Roman stressed most was the third: cram several kinds of work into one interface, and users feel like they’re looking at “three visions sharing one screen.” Silicon Valley has a perfect phrase for this: shipping your org chart to your users.

Every B2B software builder should copy that line into their notebook.

Move your internal divisions straight onto the interface, and users have to finish the map you never drew.

Here’s an analogy. A company splits into sales, marketing, and customer service, each with its own system logic. That’s your org chart. But customers don’t care how you divide work internally. They want one thing: get it done for me. When you carry your internal structure straight into the product, users have to fill in the map you never finished. For a system like CRM, which spans sales, marketing, and service, that’s especially fatal.

The price Grok Bot paid was giving up built-in distribution: users have to download one more app. In return, the team controls every pixel in that app and can redraw what work should look like in the AI era. In the long run, I think that trade pays off.

---

Colleague-pilled: one question that settles five debates

What gave this interview real weight for me was a gloriously unpolished bit of team slang: colleague-pilled, which I’d loosely call a “coworker mindset.”

It works like this. When a product debate has merit on both sides and goes nowhere, step back and ask: if this were a human coworker, what would I want them to do?

The surprising part is that this one question answers several decisions that seem unrelated.

One test brings five scattered decisions into alignment.

Five decisions, seen through the coworker mindset:

1. Don’t build into an existing tool: a coworker should have their own workspace, not share your interface
2. Give every bot its own cloud computer: a new hire doesn’t share your laptop
3. Run entirely in the cloud, always on: you don’t have to keep your computer open and watch; they come back when the work is done
4. Don’t lay out every tool call: you wouldn’t ask a coworker to report every keystroke in real time
5. Cut features, not add them: keep only what a coworker actually needs to see

You wouldn’t leave a new hire without a laptop on day one and have them share yours, so Grok Bot gives every bot its own cloud computer. That’s not just a romantic analogy; it’s practical. Many tools sales teams use have no usable API. People get that work done by clicking and typing, so an AI coworker should have that same basic ability.

You wouldn’t ask a coworker to report every key they press, second by second, so the interface doesn’t lay out each tool call. It reports progress only when there’s something to report. What early users actually wanted was the bot’s to-do list and its priorities. Nobody wanted to scroll through a long chain of thought.

You’d want a coworker to finish the job and then come back to you, not make you keep your computer on and watch, so everything lives in the cloud, making each bot a persistent entity that’s separate from your device.

Even cutting features comes from the same test. During three weeks of internal testing, the biggest change wasn’t what got added; it was how much got removed. The team filtered ideas with one internal question: how would the launch tweet for this feature read? If you can’t write one line that users would care about, maybe it shouldn’t be built. Roman even changed the template from “Grok Bot adds…” to “Grok Bot can now…”. The first usually leads to a new button or a new menu; the second forces you to think about capability, and capability often doesn’t need a single extra pixel. The result: 99% of automations on the platform are created by simply telling the bot something like, “Remind me at 8 a.m. every day.”

One detail I especially love is something they deliberately chose not to do. In the first two weeks of the internal launch, most people ran five to ten bots, each covering one line of work. By the end of the second week, some people had started “promoting” their best-performing bot to chief of staff, mostly talking only to it and letting it delegate to the others. The team noticed, but deliberately left it out of onboarding because they “didn’t want to steer people toward a particular usage.” Later, plenty of external users arrived at the same step on their own.

A good test isn’t valuable because it’s clever. It’s valuable because, at hundreds of forks in the road, it saves you one wrong turn every time.

---

What it means for B2B and manufacturing in Taiwan

Let’s bring this back to Taiwan.

We work with many manufacturers and B2B companies, and the place they most often get stuck with AI adoption is exactly this: they expect AI to be an “extra feature,” a chat box, a button, a plug-in. It gets installed, and then what? Nobody actually hands work over to it.

Treating AI as a coworker means weaving it into real workflows, not adding another plug-in someone has to feed with data.

The coworker mindset offers a blunt reminder. When adopting an AI agent, don’t ask, “Can this tool plug in?” Ask, “If I hired a new coworker, what would they need to do the job?” They need a workspace, access to the systems you use every day, an onboarding process, and your time to get them up to speed. That’s exactly why, in the interview, core team members personally onboarded two to three hundred people, call after call, turning every point of friction into a must-fix for the next day. Many legacy systems in Taiwan have no clean API; people run them with a mouse and keyboard. Treating AI as a coworker actually fits the reality on the ground better (a point we keep coming back to when we talk about practical approaches to bringing AI into CRM).

This has always been how OakMega thinks: CRM isn’t a collection of fields; it’s the vehicle for the customer journey. We’ve built that belief into the product. Modules like Portals and Forms are, at their core, about preparing the workspace and first-party data an AI coworker needs. When AI steps into that journey, it should act like a coworker who understands the context, not one more form someone has to feed with data.

But I want to add a note of caution. Roman put it plainly: the things that made this version succeed will be taken apart, piece by piece, by their own team, because what models can do three months from now will once again make today’s design redundant. Every company adopting AI should keep that in mind. There’s no “set it and forget it” in AI adoption. Every right call you make today may simply be preparation for a better teardown next time.

So I won’t tell you to copy Grok Bot. I’ll tell you to find your own question. For them, it was “What if this were a human coworker?” For your organization, it might be something else. Real competitive advantage has never been about how many features you add. It’s about whether you have one test that keeps hundreds of micro-decisions pointing in the same direction.

It’ll be fascinating to look back on this a year from now. By then, the answer will have surfaced on its own.

---

FAQ

Q1: What exactly does “colleague-pilled” (the coworker mindset) mean?
It’s a test for product decisions. When a team is deadlocked over a design and both sides have a point, step back and ask, “If this were a human coworker, what would I want them to do?” That question unifies judgment calls that would otherwise be scattered, so a large number of micro-decisions point in the same direction.

Q2: Why is “shipping your org chart to your users” a bad thing?
Because it hands your internal division of labor straight to users and leaves them to understand and piece it together. Users want to get things done, not first figure out how your company is organized. For a CRM that spans sales, marketing, and service, slicing the interface this way is especially likely to leave people stuck.

Q3: What can small and midsize businesses adopting AI take away from this?
Don’t treat AI as “one more feature.” Think of it as hiring a new coworker: what workspace does it need, can it reach the systems you use every day, and is someone there to get it up to speed? That lens is more practical than chasing any single feature, and it makes it far more likely you’ll actually hand work over.

Q4: If today’s design will be torn down anyway, is adopting AI now still worth it?
Yes. The goal isn’t to build a system that never changes; it’s to establish a test and a process you can keep iterating on. Today’s right decisions pave the way for the next, better adjustment. If something gets torn down, that’s a sign you’re moving at the right pace.

---

References

• Lenny's Podcast, "The team behind Grok Bot on building AI colleagues" (aired 2025-09-08): https://www.youtube.com/watch?v=maSdsTLaMuU
• Business Next (Taiwan), interview write-up: “What does it mean to build an AI prototype in one month?” (source material for this article)