Steve Taplin interviews Vurvey Labs CTO Eric Poff about Vurvey’s human-centered market research platform, how AI personas are grounded in real human data to reduce hallucinations, and how stronger process (Jira discipline, hybrid cadence, and AI-assisted requirements) improves delivery. Eric also explains how a “fast team” uses vibe coding tools like Lovable and Replit for rapid prototypes, while keeping engineers in the loop before anything reaches production and why operational quality signals matter more than vanity metrics.
In this episode of Software Leaders Uncensored, host Steve Taplin (CEO of Sonatafy Technology and author of Fail Hard, Win Big) speaks with Eric Poff, a seasoned technology executive and CTO at Vurvey Labs. The conversation covers Vurvey’s platform for market research and feedback, how the company uses AI while keeping humans central, and how Eric approaches execution, process, metrics, and communication as a CTO.
What Vurvey Labs is and what it does
Eric explains that Vurvey is short for “Video Survey”. He describes Vurvey Labs as a platform used for market research, ideation, concept creation, and feedback, with an emphasis on collecting human feedback. He says the platform originated around sending consumers on “missions” (such as trips to a store) where they record video on their phones while describing what they see, think, and feel. He gives examples like recording a store mission or doing a closet tour to capture information that brands can use as feedback.
Eric says Vurvey’s customers are large brands that use the platform to research ideas, generate concepts, and gather feedback. He emphasizes that Vurvey keeps “the human at the center,” describing the company’s approach as human-centered AI.
How Eric became CTO at Vurvey Labs
Steve asks how Eric landed the role. Eric traces his early interest in technology back to a database class at the University of Cincinnati, describing how he learned to translate language into data models (nouns as entities, verbs as relationships) and became passionate about data.
He then describes his early career at Chiquita in Cincinnati, where he was exposed to multiple areas of IT (including mainframes, AS/400s, telecom, application development), eventually spending 11 years on the data team.
For Vurvey Labs specifically, Eric says he knew the founder well and the role came out of a conversation. He asked about the amount of data the company had and whether it had been productized. Eric says the founder responded that he needed someone like Eric, and Eric ties that directly to his data background. He emphasizes that he did not get the role through a LinkedIn posting, but through relationships and matching his strengths to what the company needed.
AI work at Vurvey: “sense make,” a people model, and grounded personas
Steve asks about cutting-edge projects. Eric says Vurvey was working on AI “when it was still called machine learning.” He describes an internal process for extracting key concepts from human-collected data, which Vurvey calls “sense make”. He states the company has a patent related to that work.
Eric explains that Vurvey uses the processed human data to power AI personas through two models: sense make and a people model. He says the goal is to help customers ideate while keeping outputs grounded in reality. He references the hallucination issue with LLMs and says Vurvey addresses trust by grounding persona responses in real human data. He gives an example question a customer might ask (how a certain demographic would react to a product idea) and says customers can still ask real humans, but can also ask the AI personas, with the responses traceable back to human feedback.
Engineering team size and workflow
Eric describes Vurvey’s engineering group as small but mighty, with 8 to 10 engineers, including full-stack and front-end engineers and a few QA-focused developers. He says the team uses a Jira-centered process to organize work and avoid losing decisions in Slack or email. He describes a refinement process to clarify requirements and priorities, emphasizing that engineering moves faster when requirements are clear and “gray area” is minimized.
He also mentions tool integration, such as linking pull requests to Jira and updating statuses (for example, when something is approved or ready for testing), then handing it to assigned QA for testing before deployment.
QA and automation
Steve asks about automated QA. Eric says they have some automation, but still emphasize humans in the loop, including engineers reviewing other engineers’ work. He mentions using tools like Claude Code to help identify issues as an early pass, such as flagging critical bugs before code goes to human review.
He also says they have explored user testing automation for their web platform, noting it’s difficult to script interactions. He expresses interest in newer model capabilities like “computer use,” describing the idea of having Claude log into their app and run a test script, but says they have not fully implemented that yet.
Work model: hybrid with daily standups
Eric says Vurvey Labs is hybrid, with most engineering staff in the Cincinnati office, along with some contributors in other locations globally. He says they use daily standups, kept short and focused on current work and blockers, and emphasizes that live virtual meetings help prevent work from getting lost in Slack messages.
Product and engineering alignment and the CPTO discussion
Steve asks how product and engineering are organized and stay in sync. Eric explains that the company has two main parts: customer/account teams and a product organization that he leads. He says the product side includes product management and a data team focused on AI capabilities, with leaders for each area.
He describes product managers working closely with customer teams to capture needs and frustrations, then using Jira so engineering work connects directly to customer needs. Engineering stays aligned by asking questions back to product managers and working from the organized requirements.
Steve brings up the idea of combining Chief Product Officer and CTO into a CPTO role. Eric says it’s important to keep product and technology connected because conflicts will occur. He notes the CTO perspective often emphasizes predictability and managing tech debt, while product is pushed toward market demands and “the next best thing.” He says when there are two roles, the CEO often becomes the decision-maker when conflicts arise.
“Fast team” vs “stable team” and experimentation
Eric describes an approach Vurvey is experimenting with: a more experimental “fast” team working on new ideas (including pulling engineers and a product innovation person onto an experimental branch), alongside a team focused on tech debt, bugs, and incremental enhancements. He describes taking experimental learnings, demoing internally, getting buy-in, and then breaking the work down into deliverable chunks.
Vibe coding for prototyping
Steve asks about vibe coding, and Eric confirms it’s part of the fast team’s workflow. He describes how vibe coding helps them move beyond whiteboards and documents by seeing UI concepts in real time, quickly iterating when something doesn’t look right.
When asked about tools, Eric lists Lovable, Replit, and Google’s AI Studio, noting Replit’s capabilities and the role of prompting and hosting in that workflow.
Steve asks whether vibe-coded output should go to production. Eric says he agrees it’s useful to start there, but says he would not allow vibe-coded software to go into their platform without an engineer reviewing it. He says boilerplate can be fine, but emphasizes review and understanding, and expresses skepticism about claims of replacing large portions of engineering teams through vibe coding alone.
Process changes that improved delivery
Eric describes a process change aimed at moving from whiteboard to execution faster. He says the team now brings a laptop into meetings, starts a Google Meet, turns on Gemini with transcription, and captures free-form discussion. They then use the summary as a starting point and apply AI prompts like “act like a product manager” to break the conversation into Jira tickets, with acceptance criteria and missing considerations. He says this speeds delivery and can surface gaps the team might otherwise miss (such as overlooked options or fallback paths).
Metrics: what matters and what doesn’t
Eric says he focuses on operational metrics, including reported bugs and error and warning logs, particularly issues that may remain hidden until customers report them. He criticizes metrics like “number of commits” as not meaningful on their own, arguing that bug and error rates better reflect software quality.
Common mistakes Eric says organizations make
Eric points to poor communication as a recurring failure mode—when engineers build in a vacuum, surrounded only by other engineers, without regularly involving the business side or the actual users. He recommends taking time to validate understanding with business stakeholders, restating the problem and proposed solution before executing, and doing checkpoints throughout development.
Communicating with non-technical stakeholders
Steve asks about communicating with executives, boards, and investors. Eric says communication is essential at the C-level and describes the need to translate technical work into non-technical terms. He emphasizes speaking in the stakeholder’s language—for example, framing work in terms of customer retention or business impact rather than internal technical functions. He says he tries to lead with the use case and business problem and keep technical details secondary.
Eric’s “No BS” advice
Eric’s closing advice is to surround yourself with people who think differently than you. He says those people will challenge your assumptions, and that’s usually beneficial.
