Kyle Phillips Bet On A Different Way To Build Ninety.io’s Mobile App

Every team that adds a new platform for an existing product faces the same pressure. Match what the flagship version already does, or customers will notice what’s missing.

Kyle Phillips, previously Head of Product at Ninety.io and current Chief Product Officer at ActiveComply, bet against that instinct when his team finally built the Ninety.io mobile app customers had been requesting for years.

Ninety’s desktop product is feature-rich, and copying it feature-for-feature onto a phone would have been the safe, expected move.

Phillips did the opposite. He cut aggressively, shipped something narrower than felt comfortable, and let real usage, not a feature checklist, decide what came next.

The Good sat down with Phillips to talk about how he and his team decided what belonged in that first version, why they skipped native development, and how they knew the bet was paying off once real customers got their hands on it.

Mobile wasn’t optional anymore

Ninety.io makes software for companies running the Entrepreneurial Operating System (EOS), a framework leadership teams use to set strategic goals, track progress on a scorecard, and run structured weekly meetings. That’s a small, defined audience, which is exactly why the case for mobile wasn’t obvious at first. But there were a slew of reasons that eventually pushed Phillips and his team to prioritize it.

First, that work of planning and goal-setting had historically happened at a desk. But the user profile changed over time. “You have people who are not just at the desktop; think construction and other workers out in the field,” he says.

Additionally, Ninety is used so heavily by leadership that Phillips saw mobile as a way to pull the rest of a company into the product. “We knew that companies will benefit more from our product if more of the company is on it,” he says. “So [mobile would enable] our existing customers and leadership people to stay in touch with their teams… getting lower-level managers or individual contributors on the product.”

Underneath all of it was an additional motivation Phillips saw playing out across B2B software generally. “Everything’s being designed mobile-first now,” Phillips says. “Having a mobile app, and having it be a good experience for productivity, is table stakes for a lot of businesses.”

Approaching the project without feature parity and on a deadline

As the team began the project, they acknowledged there was a design debt to reckon with. Ninety’s desktop product had been built years earlier and wasn’t designed with mobile patterns in mind. It was usable on a phone, but not a good experience.

And the timeline was real. Phillips wanted the beta live before Ninety’s largest annual customer conference, so the team could put it directly in front of the customers who’d been asking for it.

An outdated foundation and a hard deadline pushed Phillips toward a very different question than most teams start with. Instead of asking what was missing compared to desktop, his team asked what someone actually needed to get done on day one.

“We took a really hard look at what are the jobs to be done and what does someone need to do on the go,” he says. Not everything in a feature-rich desktop product needed to earn a place on a phone. The team built around a narrower version of the product, including a clear list of what someone needs to do today, with everything else quieted down.

Deciding what belonged on mobile was one question. Deciding what belonged in the first version of it was a separate one, and the clearest example of that second question was a feature that, on paper, looks non-negotiable: forgot-password.

A forgot-password function was never in question as a mobile use case. Desktop already had it, and mobile customers would eventually need it too. The only real question was whether it had to exist before a single customer opened the app for the first time. It didn’t.

“If somebody had brought that up to me and said, ‘Hey, we need this in there,’ you’d probably say, ‘Yeah, well, of course you do,'” Phillips says. “But we rolled it out, and not a single person said it. We did it as a later iteration.”

Native wasn’t the goal either

The same instinct shaped a much bigger decision of how to build the app at all. Developing separately for iOS and Android is expensive, so Phillips’s team asked what they actually needed rather than what looked most impressive.

“Do you need to be native out of the gate? Not really,” he says. They used a cross-platform framework that gave the app a native feel without the cost of building fully native apps for each platform.

Similar logic carried into design. Rather than invent new mobile patterns, the team leaned on ones customers already knew from other apps. The idea was to “make it so that when somebody opens the app, it’s very intuitive, so they’re not hunting. [They] do these things on other apps, [and Ninety.io can] operate the same way,” he says.

Betting on unfinished

Underneath the scoping decisions was a broader philosophy Phillips is direct about. They weren’t waiting for the product to be finished before shipping, and he suggests other product leaders in a similar situation do the same.

“I try not to wait for perfection by any means,” he says. “I try to get something out early, let people provide feedback, and I find that sometimes that can be a faster way to actually have people like your product more, because they feel like they’re partaking in the conversation of it.”

He’s watched the alternative fail. “If you try to get it all out and make it perfect, and then [users] don’t like it, they give you that pretty harsh review,” he says. Aim for completion, and you’re judged against an impossible bar. Ship something narrow and real, and customers judge it as a start, not a verdict.

Collecting feedback and iterating on the early success

When you ship something half-done, you can’t be slow about improving the product. So, after launching the app, Phillips and his team began collecting feedback for next iterations.

Ninety serves more than 16,000 customers across very different industries, which rules out the approach that works for a smaller B2B vendor: calling up your handful of biggest accounts and asking them what they think.

“It’s not like enterprise where you talk to a couple people, and you could pretty much get the idea of what you should do,” Phillips says. “We have to gather feedback in every way possible, and then somehow filter it down into what is the right thing.”

That meant triangulating rather than relying on any single source, including reviewing in-app behavior data from tools like FullStory and Gainsight, direct outreach to both the heaviest users and the people who hadn’t adopted the app at all, and ensuring every single App Store review was personally answered.

“I was looking at who were the heaviest users. Why are you using it all day compared to somebody else?” he says. “As well as looking at the people who were not using it and finding out why.”

Confirming the bet

In his own launch, Phillips tracked a mix of signals rather than one metric. “How I knew beta was working was, we saw the adoption — people downloading it really quickly and watching them do at least a few things in the app, looking to see how many people were returning each day,” he says. “Also watching support requests. Seeing if people were letting us know when they didn’t know how to do something, or asking ‘Where is this feature?'”

He also had a specific pattern he was watching for. Ninety’s desktop usage spikes on Mondays and tapers off by Friday, tracking the rhythm of a typical workweek. “With the mobile app, I’m hoping to create more of a flat plane, where people are using it more consistently, because they don’t have to be at their desktop,” he says. This was a hypothesis he could only test once real usage data came in, not before.

The results backed up the bet. Within 30 days of launch, the app reached roughly 30,000 users and landed in the top 100 business apps in the App Store.

And the feedback that came in read more like a wish list than a complaint. “I didn’t get a single bit of negative feedback about the design,” Phillips says. “People gave feedback saying, ‘I would like to have certain features,’ but nobody said, ‘this thing is difficult to use.'”

The lesson beyond mobile

Phillips was solving a mobile-specific problem, but the underlying discipline isn’t specific to mobile at all. It comes down to a habit any product team can borrow: resist the pull toward matching what already exists, ship the narrowest version that solves a real, immediate task, and let actual usage, not a features list, tell you what to build next.

That’s a harder habit to hold onto than it sounds. It’s easy to justify a feature by pointing to what a competitor has, or what the existing product already does elsewhere. It’s much harder to ask, as Phillips effectively did with the forgot-password flow, whether anyone will actually notice if it’s missing on day one. Teams that skip that question tend to ship bigger, later, and with less certainty that any of it was necessary.

A final thought

None of this was guaranteed to work out the way it did. A team convinced it needed feature parity, full native development, and a polished first release would have shipped later, spent more, and had no more certainty that any of the extra work mattered to customers. Phillips bet that a narrower, rougher version, tested in the open, would tell him more than a longer build cycle ever could. It did.

Kyle Phillips talks more about building Ninety.io’s mobile app on Ninety’s Founder’s Framework podcast.

If your team is trying to figure out what actually belongs in a v1, rather than guessing at feature parity, research and testing with real users before you build can tell you which gaps customers will forgive and which ones they won’t. Get in touch to see how a structured research program could help.