Clients offer feedback to customer success representatives, who pass it along to product teams, who — possibly — pass that feedback on to engineers.
Along the way, things can get lost in translation. Maybe a client was promised a feature that’s way too complicated to deliver. Maybe they were offered a roundabout solution for what could have been an easy fix.
Breakdowns in the communication chain between the people who use software and the people who build it are a top pain point for software organizations. So why not eliminate the chain altogether?
That’s what Nayya, a New York-based employee benefits platform, did. Instead of relying on intermediaries to relay customer needs, Nayya’s engineers sit in on client calls, listening and offering workable solutions in real time.
“Last week was a particularly busy week, and I sat in on maybe a dozen,” Nayya director of engineering Josh Brown told Built In. “This week, I declined a bunch of meetings to get some deeper work done, but I still sat in on three today.”
Call attendance isn’t mandatory, Brown noted, and the set-up isn’t for everyone. Some engineers want to remain hands-on-keyboard and leave the customer chats to others. But for technologists who fall into the category Nayya head of product Aman Magoon calls “all-around athletes,” it’s a big advantage.
We’ve optimized our hiring ... by looking for all-around athletes and not really position players.”
“We’ve optimized our hiring — when it comes to engineering or product or commercial — by looking for all-around athletes and not really position players,” Magoon said. “We’re looking for someone who can lead a business development call if they have to.”
That jack-of-all-trades approach works great for now, with just three engineers and two product-engineer hybrids on Nayya’s development team. But what about when the company scales — could there ever be an organization composed of dozens (or even hundreds) of all-around athletes?
The Nayya team thinks so. That’s because the benefits of direct customer-engineer relationships scale, no matter an organization’s size.
Nothing Gets Lost in Translation
Before co-founding Nayya, CTO Akash Magoon led a 15-person engineering team at Enigma, a data management company. At some point, he decided to try things a bit differently, sending engineers and product people into customer meetings to build face-to-face relationships.
When he started his own company, he took the approach with him, because it significantly improved communication between software users and software makers. Requirements and user stories come directly from the source, and there are fewer opportunities for wires to get crossed.
For instance: Nayya caters to a variety of stakeholders, from insurance carriers to brokers to companies to employees. On one call, a broker mentioned that a corporate HR manager had passed along some feedback — employees were struggling to figure out if their existing healthcare providers were in-network during Nayya’s digital insurance plan selection process.
An engineer suggested adding a find-your-provider search function during the open enrollment sequence. The feature was added to the team’s weeklong sprint, along with a handful of other open enrollment functionalities, and engineers spun up an MVP within days.
We’ll design, build and test the product with our users.”
Brown was one of those engineers. Because coders are present for an idea’s inception, its demos and its eventual implementation and support, it’s easier to get a clear view of a product’s purpose and optimal design, he said.
“We’ll design, build and test the product with our users,” Brown said. “It’ll go all the way through to the user testing it out, and iterating on top of that once we hear the feedback, which helps deliver a product that they’ll end up enjoying to use.”
Engineers Are Bolder With Minimum Viable Products
Short sprint cycles and rapid back-and-forth with customers means engineers can take bigger swings with MVPs. In that way, Nayya’s approach is classically agile, even though engineers don’t use the word in-shop.
“If an engineer is on a call and a customer points out a potential improvement, the engineer knows how easy that could be, as opposed to how difficult somebody on the business end might think it is,” Brown said. “Then, you can just implement it super quickly, and it doesn’t even need to get prioritized because almost by the end of the call, it’s already been implemented.”
Other times, tasks that emerge from customer calls get folded into Nayya’s one-week sprints. Individual developers plan and execute their own features, with check-ins from product managers like Aman Magoon and occasional code reviews from peers. Every Friday, each engineer presents their work and decides — often unilaterally — whether to ship the new code.
It allows us to move with speed and intention, as opposed to saying, ‘OK, let me loop in my engineer or my product person to get you a timeline on that.’”
Because feedback from customers is immediate and direct, shipping unfinished products is no big deal, Akash Magoon said. It also prevents over-engineering, which, for a seed-stage startup, can be death. To avoid over-engineering and the technical debt that comes with it, the Nayya team asks, “What’s a two- to three-day solution we can ship to customers and test?”
“Because we have engineers on on our calls who are able to, like, T-shirt size certain requests on the fly because they’re so intimately familiar with the technology, it allows us to move with speed and intention, as opposed to saying, ‘OK, let me loop in my engineer or my product person to get you a timeline on that,’” Aman Magoon added.
Engineers Fix — and Prevent — Problems in Real Time
Engineers aren’t the only Nayya representatives on customer calls — customer success and product people are there too. Those team members can field a variety of client concerns and further ease communication. But sometimes, an engineer’s perspective is essential.
Engineers, for example, are familiar with the dependencies in a product’s codebase. If a client asks for a feature that would create a tangled web of code, engineers can sound the alarm before the team wastes valuable time — or at least alert customers that their idea is heavier-lift than they anticipated.
The engineer can actually say: ‘I know why this broke down. I know why you had this outage and I can ensure it’ll never happen again because of this fix I’m about to make.’”
Sometimes, though, complicated features are worth the investment — especially if they can serve as leverage with other channel partners, Aman Magoon said. In that scenario, engineers are best positioned to make on-the-fly effort estimations, which help the team decide whether to agree to a new build.
Second, if a customer brings up a technical problem on a call attended by engineers, that customer gets more than an apology.
“The engineer can actually say: ‘I know why this broke down. I know why you had this outage and I can ensure it’ll never happen again because of this fix I’m about to make,’” Aman Magoon said. “The one-two punch of both customer success and engineering being there live with the stakeholder as they go through the one or two meltdown moments they’ll have in a year is kind of an amazing thing.”
Last, engineers help shorten the company’s long sales cycles by answering questions right off the bat that would usually surface farther down the funnel.
Customer Needs Become Intuitive
Empathy is a hot concept in the world of development and design, and for good reason — putting yourself in users’ shoes makes products more intuitive, inclusive and innovative. Including engineering on client calls promotes user empathy in an organization, Aman Magoon said. After weeks and months getting to know the client and its business, there’s less guesswork involved.
“Because the engineer understands the pain points of the end user super intimately, they’re more inclined to empathize with them and then to build not only the feature they’re asking for, but the next few features that stakeholder isn’t even thinking about yet,” he said.
Nayya’s engineering backlog has become a two-way street, with customers coming to engineers with suggestions and engineers returning with ideas of their own. Because of their familiarity with clients’ needs, engineers can pitch features that address those needs before customers explicitly ask. That saves time that might otherwise be spent negotiating about the feasibility or technical requirements of features customers dream up themselves.
“It’s like that Henry Ford quote,” Akash Magoon said, “‘If I had asked people what they wanted, they would have said faster horses.’”
Each week, commercial, product and engineering team members come together to discuss what jumped out to them on customer calls. From there, they’ll identify customer needs and prioritize new tickets based on value to end users and level of complexity.
It’s like that Henry Ford quote: ‘If I had asked people what they wanted, they would have said faster horses.’”
It’s a balancing act between fun technical innovation and value-driven deliverables, Aman Magoon said. Engineers push the platform forward with new ways to leverage data and technology, and product and commercial team members continually ask what advantages those advancements bring to customers.
“We haven’t come across too many situations where engineering is coming up with a feature idea completely out of left field, because they’re so in tune with what’s happening on the ground,” he said. “But our belief is that, by empowering the engineer to make product decisions, we’ll ultimately have a product that’s more innovative and further developed than if we led with commercially driven prioritization.”
Engineers Are Happier at Work
Technical accomplishments help engineers feel fulfilled at work. But many are also motivated by relationships — including those with customers.
Brown has worked at offices with more siloed engineering teams, and he prefers Nayya’s set-up, he said. The requirements are clearer, the work happens faster and he actually gets to see the responses to what he builds.
“Once it’s complete and you get to show it off, you get to actually see people’s faces when they say, ‘Oh my god, this is really going to save so much time and so much money,’” he said. “That’s not something you get to see with other methods.”
Instead of lobbing requirements and deliverables back and forth over a wall, customers and engineers get to work together on every step of the development process. This gives engineers more ownership over their work and its results.
“We treat everyone like an entrepreneur,” Akash Magoon said.
You get to actually see people’s faces when they say, ‘Oh my god, this is really going to save so much time and so much money.’”
But does working so closely with customers ever get annoying? Brown said no.
“We don’t always do exactly what they say,” Brown said. “But we do think about it and decide what’s best, because maybe they suggested one thing, but doing another thing actually solves their problem for them.”
And what about customers — do they ever get frustrated or confused when engineers talk tech during meetings?
Again, nope. Aman Magoon said customers are grateful when engineers explain the technical requirements of the features they want. It means there’s less of a chance their ideas will get killed down the line, or disappear into the ether once the meeting ends.
At small startups, an all-hands-on-deck mentality is easier to pull off. But all three Nayya team members said they expect the set-up to scale. Friday product show-and-tells would break up into separate groups, and engineers would selectively attend customer meetings based on their personal assignments and areas of innovation for the company. The breakneck sprints and close engineer-customer relationships, however, would stay the same.
“We definitely want there to be 100 engineers that are able to utilize this whole framework,” Brown said. “We think about that from the hiring process all the way through.”
