Rox has no product managers. When Shriram Sridharan told me that, the part I wanted to understand was what happened to the work.
Someone still has to speak to customers, decide what matters, design the experience, and make sure the product works. At Rox, Shriram described those responsibilities coming together in the product engineer: the person who understands the customer’s problem also builds the solution and gets it into production.
“Engineers directly talk to customers and then build from there,” he said.
That was the part of our conversation on Inside the Silicon Mind that stayed with me. AI can help a team produce software faster. The opportunity for a founder is to use that speed to shorten the distance between a customer having a problem and someone taking responsibility for solving it.
Give the builder the whole problem
Shriram, co-founder and CTO of Rox, described a role that spans customer requirements, design, frontend and backend development, and deployment. Work that previously passed between several people can increasingly sit with one engineer using AI agents.
The interesting question for a founder is how much customer understanding survives those handoffs today.
A customer explains why a task is difficult. Someone turns that conversation into a requirement. Someone else designs a screen. An engineer receives a ticket. By the time work begins, the team may have a precise description of the feature and a much thinner understanding of why anyone needs it.
That is an example of the problem I would look for in an early company. If the builder only sees the requested feature, they have fewer chances to challenge it, suggest a simpler answer, or notice that the real problem sits somewhere else.
You can test this without reorganizing the company. Bring the engineer responsible for a feature into the customer conversation. Ask them to explain the problem back in their own words, including what the customer does today and why that falls short. Then keep them involved when the customer tries the result.
A useful question at that final step is: did the customer finish the job they came here to do? The answer can be very different from whether the team delivered the ticket.
Learn how quickly someone changes their mind
Shriram calls his hiring preference “slope over intercept.” Intercept is what someone already knows. Slope is how quickly they can learn.
He connected that distinction to the way engineers now use agents. Generating more code is easy. The harder work is recognizing where the output is useful, where it is unreliable, and what needs to change.
In my world of recruitment, that is a more revealing conversation than asking someone which tools they use. I want to hear about a time they were wrong. What did they initially believe? What evidence changed their view? What did they do differently afterward?
For a founder, I would apply the same scrutiny to the team’s customer learning. When did a customer last change your mind about the product? How long did it take to act on what you learned? Did anyone go back to find out whether the change helped?
A team can release something every day and keep making the same mistake. The useful speed is the time it takes to discover that mistake, understand it, and put a better answer in front of the customer.
That also makes learning easier to assess. You can look at a specific decision, the evidence behind it, and what happened next. You do not have to rely on someone describing themselves as adaptable.
Put your own work through the product
Rox takes a particularly direct approach to learning from use. Shriram said the company runs its sales work on Rox, with no other sales tool. Its salespeople report problems in an internal channel called Rox on Rox, and he described issue resolution happening in minutes.
There is a useful pressure in that arrangement. A problem in the product interrupts the company’s own work. The people building it can hear about that problem while it is still fresh, from someone who can explain exactly what they were trying to accomplish.
It also gives the sales team something concrete to show a prospect. Shriram described them explaining how Rox helped generate the outreach, prepare the material, and book the meeting they were now having.
For a founder, the lesson I take is to find a recurring piece of work that makes your team depend on the product. Where that is practical, use it under ordinary working conditions, including the awkward cases you would leave out of a demonstration.
Then check those lessons with external customers. Your colleagues know the product, can reach the engineers, and have a reason to persist through a bad experience. A new customer may simply leave. Internal use can uncover problems quickly; customer use tells you whether the solution travels.
Keep responsibility with the person who ships it
Shriram was careful about where he trusts agents. He distinguished general product work from the deeper infrastructure connecting enterprise data systems, where security and correctness require close attention.
He also named two skills he still values: reviewing generated work well enough to stand behind it, and debugging it when something goes wrong in production.
Those responsibilities matter when one person can build and deploy much more than before. The customer still needs someone to answer for the result.
Near the end of our conversation, Shriram recommended Extreme Ownership. His takeaway as a first-time founder was that a leader has to examine their own planning, training, and communication when something fails. He described Rox starting from the position, “I’m accountable for everything.”
I think that connects directly to the product engineer idea. Give someone the context and authority to solve a customer’s problem, then make sure they remain involved long enough to see what their work actually did.
Try it on one customer problem
Choose a customer problem your team is already planning to address. Put the person who will build the solution in the next conversation with that customer.
Agree on the result the customer needs, decide how you will check it, and give one person responsibility for following it through. After the change ships, have that person watch the customer use it.
You may discover that the feature was right. You may discover that a small change would have solved the problem, or that you misunderstood it entirely. Each answer is useful if the team hears it soon enough to act.
That is the opportunity I took from Shriram’s approach: a builder who can hear the problem, make a decision, and stay with the customer until the work pays off.
How many people does a customer’s problem pass through before it reaches someone who can solve it?