Jinlin Zhang, CTO of Physical Turing, has built many AI startups through early-stage pivots and technical rebuilds.
In the past year, I have been the technical cofounder of three startups. The first was an AI-powered digital audio workstation built for music producers. The second was a mobile app for creating digital cards and video gifts. The third helped parents generate and read personalized storybooks for their kids.
I started building the music app convinced that the job of a technical founder was to be the deepest engineer in the room. Three pivots later, I think that was close to backward. The founders I admire the most are not the ones who know a single stack cold. In the AI era, they are the ones who can learn about their users and adapt to new needs quickly and cheaply.
Learn the user before you optimize the system.
Each of my three products punished a different instinct. With the audio workstation, the thing that mattered was latency. A producer can feel 30 milliseconds of delay, so I spent two weeks optimizing our audio scheduling in WebAssembly to save milliseconds. On the gifting app, users cared less about latency, and what mattered was the half-second when a recipient opened a video gift and either teared up or shrugged. With the storybook app, my users were now parents and 5-year-olds, and the work became trust and simplicity: an AI that could never show objectionable content by the parent’s standards, and an interface built for kids.
The most forward motion we have ever gotten came from the least glamorous thing we do: asking users what they want, then watching what they actually do. On the storybook app, I spent weeks building a fully custom reader interface, a feature I was sure users wanted. It ended up pulling down retention and engagement rates. On instinct, I would have shipped it and never understood why the numbers were sliding. For a startup, customer learning and user feedback are not overhead; it is how the team stops guessing instead of arguing with whoever sounds more confident.
Great CTOs also understand the importance of gaining user trust over product development. It has never been easier to build an MVP. With today’s models, you can demo a startup idea in an afternoon. The harder thing, and the more powerful one, is earning a user’s trust in your product: The gap between a storybook demo and one that parents trust their kids with for entertainment and education is big.
Trust does not come from a clever feature. It accrues slowly, across hundreds of small moments where the product does the safe, expected thing. Successful teams spend their time building trustworthy, user-validated features, not 100 cheap ones.
Build the things you are willing to delete.
Across all pivots, the work I was proudest of was usually the first thing we threw out when we changed direction. That used to bother me. If something took weeks to build, deleting it felt like proof that we had wasted the time. I do not think that anymore. A startup is supposed to make a sharp bet on something that might make the product different. Sometimes that bet is the audio engine, the emotional reveal or the full customization. If the bet is right, it can be what sets the company apart, but if the market teaches you otherwise, you have to be willing to delete it.
The solution is not to make every decision disposable. It is to avoid making every decision depend on the same bet. What survived our pivots was rarely the clever, domain-specific work. What survived was the scaffolding around it: auth, deployment and thin model provider wrappers. The boring infrastructure mattered because it meant a pivot did not send us back to zero. We could throw away the product bet without throwing away the company’s ability to build the next one.
The engineering is rarely what kills a company anyway. More than 40% of startups die not because of bad technology but because of having built something nobody wanted. What made me useful was never how clean a given system was. It was how fast my team could pick up a new customer and adjust our stack to fit their needs. This is why knowing the customer is not separate from the technical work; it tells you which parts of the system deserve conviction and which parts need to stay flexible.
As a startup, the market you are in today probably is not the one you will scale. The technical founders I trust the most are not always the strongest engineers in the room. They understand who they are building for, and they iterate quickly, humbly and flexibly. I try to hire for that, and I try to keep checking for it in myself.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
