AI Can Build It, But It Can't Decide What Matters: A Conversation with Cody Rogers

This one is a little different. Cody Rogers isn't a guest I met fifteen minutes before hitting record. We worked together at Hubstaff for years, argued about product and sales and feature requests, probably annoyed each other more than once, and had a few drinks along the way. Cody started in design, spent time at eBay, and has now spent more than eight years at Hubstaff, where he's chief product officer. The throughline of his career is a job that kept changing under him: from building things himself to building the teams and systems that decide what gets built in the first place. So we got into what breaks when you stay with one product long enough to watch your own assumptions fall apart, when listening to customers tips into letting them design the product, and whether becoming an executive slowly pulls you away from the things that made you good.

What eight years changes

Would the person who joined Hubstaff recognize how he thinks about product today? Not a lot, he says. On day one the company had thirty people and he was effectively head of product, the PM, and the designer all at once, planning the roadmap directly with the CEO and shipping on gut feel, intuition, and whatever customers asked for. He's fond of that phase, the speed is the fun part, and AI has brought some of that speed back along with the old pressure to move fast. But it also brought back the weight behind the speed: are we building the right thing? Early on, by his own admission, they didn't answer that as well as they should have. Strategy was the weak muscle, and it's the one that took years to build.

Why one person can't be the whole product

The seductive AI-era idea is the product builder: one person who does the PM work, the design, and the development, and ships the whole thing. Cody's answer is that it's unlikely you'll find someone who can do all three and wants to make the business calls, design it, build it, make it scale, and then go run an hour of enablement for sales and success. At the earliest startup stage, sure, that's basically what a founder is. But at seven or ten teams, letting everyone build their own thing produces islands. Here's my little product island, here's mine over there. The user doesn't experience the product as islands, so they arrive to something disjointed where nothing matches, and half of what got built is stuff they never needed.

The interface was never the hard part

He started as a designer, so I asked when he realized that designing the interface was the easy side and deciding what to build was the hard problem. He's careful here: design isn't easy, and it's especially easy to minimize now that Claude can make something look beautiful. But there are pieces upstream that, if you get them wrong, make the design irrelevant. Choose the wrong problem, and a designer can produce a gorgeous interface, still working hard, and it won't matter, because nobody will pay for it or use it. The fix is no disconnect: the PM, the designer, and even the engineer all understand why they're building this, how they'll measure whether it worked, and how it ladders up to the metrics that matter. Miss one of those and the design can't save you.

Claude for designers: positive, if you're careful

Net positive or negative for designers? Positive, if you're careful, meaning you know which steps you're tempted to skip without thinking, and you're willing to expand your role. The step he guards most is the wireframe. It used to be a whiteboard and boxes, two or three or five rough solutions you worked through. Now it's dangerously easy to say "Claude, here's the problem, give me the solution" and get an interactive hi-fi prototype so fast and polished that everyone is dazzled and nobody thinks. If you don't spend time there, you miss it, because Claude won't reason through the problem for you. The upside is the role can expand: he has designers own the front end, delivering code built on the design system instead of a Figma file, which saves development time and levels up the designer in the process.

Sign your name on it

The guardrail against AI slop isn't really about design, it's about ownership. The problem was never that making a big document or design took too long, so speeding that up solves nothing. The real failure is letting AI take over the review and approval step, declaring it "not my step" and throwing the work down the road. Then someone downstream gets a design or a doc you didn't actually generate, asks what a piece of it means, and you have to admit you're not sure, maybe that's not even what you meant. His rule is simple: use the tools all you want, but read it, understand it, sign your name on it, and be able to defend it. Whether you wrote it or Claude did, your name is on what you deliver.

The Korean barbecue problem

Does the sameness of AI-designed interfaces mean creativity is dying? He told the story from the Lenny and Friends summit, where a speaker showed a sleek, modern SaaS website with the header blurred, the kind you'd nod at as a great tool, then revealed it was a Korean barbecue restaurant. Everyone is copying everyone, and Claude is very good at serving back whatever is trendy. But he's optimistic, because the conversation about judgment and taste and the human element is now loud enough that people are aware of the trap. LLMs are historical by nature, assembling from what has already been done, while humans can make things that have never existed. The winners will combine the two: use the tools for what they're good at, then bring the taste and the new ideas yourself, sharpened by actually talking to other people.

When customers start steering the ship

Conventional wisdom says listen to customers, and he was on the ground at Hubstaff doing exactly that. So where's the line between listening and letting customers design the product? Without a strong strategy, he says, it's easy to just collect requests, run your RICE scoring, and build, and when you're small that works well enough. But as Hubstaff grew, strategy mattered more and they began saying no to far more. Building whatever customers, sales, or success asked for lets customers steer the ship, when what their feedback should be is data points on the map you use to make your own course corrections. You collect all of it, connect the dots, and then say: great, that's half the picture, here's the half you can't see, and here's where some of it lines up with where we're going and some of it doesn't.

Who's more annoying, sales or product

From the sales seat, you bring a prospect who's willing to pay, willing being the operative word, and say just build it, and product points at a thousand requests in Productboard and no shipped product. His answer on consensus is transparency and killing the silos, because two teams in their own silos is where it gets worst, more finger-pointing, less understanding. Healthy teams that know each other extend the benefit of the doubt: I don't know exactly what that team is doing, but I trust they know their job, so I'll come with questions instead of criticism. And who's more annoying? Probably product, he admits, because product is quietly annoying, yes, great idea, give me all your feedback, and then, oh, it's in the backlog, while the salesperson is the one facing frustrated people and losing deals. What product owes in return is honesty: we want all of it, it's all valuable, and we can build about 5%, so we'll say no to almost everything, and when we say yes we'll make it very clear why, because it connects to where we're going.

Ankle biters and moats

He coined a term I still use, ankle biters: the small competitors who do one or two core features well and peel off customers who only want that much. Hubstaff's wave came with COVID, when the world went remote and a crowd of tools cloned the timer-plus-screenshots and sold it for half the price. Hubstaff lost the customers who only ever wanted screenshots, and then watched a good chunk of them drift back, because the cheap clone was buggy, wasn't reliable across a new computer or OS or browser update. The moat is unglamorous: eight years making the desktop app work on every machine, every operating system, every browser, every version. AI puts a new entrant in the same category, customers who leave to build a slice of Hubstaff themselves, and he expects a similar return trip, because maintaining your own tool every month, keeping it current, sharing access across the team, is a lot of work. He applies the same math internally: should we just build that tool? Usually no, because he doesn't want to maintain it every month, and paying for something convenient that someone else keeps updated is worth it.

The compliance moat

Security compounds the moat. SOC 2 Type 2 and HIPAA and the rest are lengthy, expensive, and demand that you have your act together, which the overnight vendors usually don't. Mid-market and enterprise buyers aren't the ones jumping to a copycat tool. A thirteen-person team that only wants screenshots might leave for a cheaper option, and good luck to them. But anyone in medical needing HIPAA, anyone needing real compliance, has three or four real options instead of thirty or forty, which is exactly the gap Hubstaff spent years and real money to sit inside.

The CPO job that isn't about product

The hardest parts of being CPO, he says, have nothing to do with product. People, first: becoming a genuinely good manager is a separate skill set you have to study and learn from the good leaders around you, and hiring great people, building career paths, letting people go, and running reorgs are all hard, because no matter how right the reorg is, people don't love change. Second, and this one he enjoys even though it isn't easy, is moving out of product itself. His old world was design, PM, process, roadmap, impact. Now he spends far more time with sales, success, and the executive team, heading into board meetings to talk about the business two years out. It's a cross-functional role aimed at whatever problem the business is facing, some of it outside his skill set, and putting on the business hat instead of the product one is fun, hard, and new all at once.

What makes a great CPO, then, is mostly people leadership: aligning and motivating people, making the direction clear with a higher-level strategy, and then getting the right people in the right seats and giving them the autonomy to figure out how to get there, learning together along the way. That's what lets a product and design org feel empowered and like they're building toward something shared.

Staying close to the customer

The danger of a cross-functional CPO is becoming the executive who hasn't talked to a customer in months but still has loud opinions about what customers want. His defense is boring and effective: get on calls, and don't let the gap open. Right now he's personally calling churned customers to understand why they left, opening with "I'm not trying to sell you," just asking where they're going and how they're solving the problem now. The PMs join success calls, and there's a quarterly contest where whoever in product joins the most customer calls gets dinner on Hubstaff. The payoff is that in any product debate, being able to name a real customer who tried this exact thing makes your voice far louder than everyone else's hypothesizing.

Why eight years

Eight years at one company is practically an arranged marriage in tech, so what keeps it exciting? Three things. He has four kids and works from home, so he sees them every day. The people: the product org is about seventeen people across thirty countries, and he's hired all but one, a group that's kind, smart, and fun to work with. And the problems are genuinely hard, never the kind of job where you float under the radar doing one thing, which he'd hate. Becoming CPO only added to that, a stack of problems he's never solved before, made extra fun and chaotic this year by AI.

What remote actually takes

He's clear-eyed about remote work, against the current backlash. Done well, it's not work minus a commute, it's a whole different operating system, and the fact that Hubstaff builds tools for distributed teams means they feel every one of the problems: async communication, Slack response norms, how much your day overlaps with a teammate in Europe. And there's a piece of in-person connection you can't fully replicate remotely, which is why they run a yearly retreat, eighty people in Barcelona last month. The answer isn't office or remote, it's balancing real in-person trust-building with the discipline of solving the async, time-zone problems, none of which happens by accident.

Key takeaways

AI brought back the speed and the old question. Moving fast is fun again, but the weight behind it, are we building the right thing, is the muscle that actually matters, and it takes years to build.

The wireframe step is where thinking lives. Skipping straight to a dazzling hi-fi prototype is the easiest way to miss the problem. Use your brain before you use the tool.

Sign your name on it. AI slop is really a review-step failure. Read it, understand it, defend it, whether you wrote it or Claude did.

Feedback is the map, not the steering wheel. Collect everything, connect the dots, then say no to about 95%, and make the yeses legible.

Stay in the room with customers. Being able to name a real person who tried the thing beats any amount of hypothesizing, so make customer calls a habit, even a contest.

Frameworks worth stealing

Say no to 95%, and explain the yeses

Product can build maybe 5% of what it hears, so make that the stated posture. Tell sales and success you want all of their feedback and that it's all valuable, that you'll say no to almost everything, and that every yes comes with a clear reason tied to where the company is going. It reframes the backlog from a black hole into a visible strategy, and it replaces silo finger-pointing with shared understanding when teams trust each other enough to ask questions instead of assigning blame.

The custom-message asterisk

When Cody posts a role, he marks the applicants who went out of their way, a short custom LinkedIn note, or, in one director's case, a four-minute video walking through Hubstaff's onboarding flow with real feedback. It isn't generated or copy-pasted, and that small, genuine effort moves you to the top of the stack. Pair it with the airport test he applies in interviews: beyond the resume's ten seconds, is this a kind, curious, thoughtful person you'd actually want to sit next to, with the soft skills, communication and organization, that are hard to teach later.

Quotes worth keeping

The lines I wrote down.

You have to have your name signed on the things you deliver, whether you wrote it or Claude wrote it.

We're going to say no to almost everything, and the stuff we say yes to, we'll make it very clear why.

LLMs are all historical. We have the ability to come up with new things that have never been done.

Rapid fire round

Same questions every guest. Quick questions, quick answers.

Best advice you've ever received? Connecting with people and building trust. More important now than ever, when so much can be emulated and everyone can be made to sound the same.

Advice you ignored and wish you'd listened to? Networking when he was younger. He worked alongside a lot of smart people at eBay and didn't take the time to know them. He's correcting it now, seeking out rooms of people wrestling with the same AI problems, because the problems are rarely unique and someone has usually already solved yours.

What would you tell your younger self? Learn AI sooner. And buy some Bitcoin.

Ongoing challenge that keeps you up at night? Nothing truly keeps him up, life and family are good. The closest is the sheer speed of change and how fast you have to keep learning, which is stressful in a mostly good, even fun, way.

Favorite spot? Chi, a Chinese place in town with surprisingly good sushi, where he and Katie go when they can get a babysitter.

Tool you can't live without? Customer conversations. Wherever he goes, staying connected to customers and tracking how much the team is talking to them is the one thing he brings with him.

---

Cody Rogers is the chief product officer at Hubstaff, where he has spent more than eight years after starting his career in design at eBay. Find him on LinkedIn.