6 Steps for Building Mobile Software


By Neil Parmar

So you want to make your startup’s mobile software development process more efficient. But where do you begin?

Ask Boris Chan. The associate director of Pivotal Labs Toronto recently visited JOLT to share his insight on how more than 250 employees, in a practice he helps oversee, effectively collaborate on a multitude of projects. Over the years, the fast-talking engineer has seen plenty of ventures struggle in their attempts to find faster, cheaper ways to build out their mobile products.

“You can misuse your resources in so many different ways, [such as] spending time building features that aren’t necessary,” says Chan, who was the director of engineering at Xtreme Labs before the Toronto-based mobile development and strategy firm got acquired by Pivotal last year.

Here’s how Chan recommends spending your resources “in a way that’s efficient and sustainable, which is not often how startups think about engineering.”

1. Validate your product

“A lot of efficiently spending your time is about building the right thing,” says Chan. “Know your users. You want to be able to validate your product’s market fit before you spend too much money [building] it.”

Once you know exactly what kind of program potential customers want, determine the platform on which they want to view it. An iOS-based app? An Android program? Or both? Chan recommends starting small by focusing on a single platform. Mailbox, for one, ran on iOS and didn’t launch its Android version until about a year after it was acquired by Dropbox—for a reported $100 million.

2. Create your user story

Chan says there are two elements to writing a strong user story:

-“The best stories communicate business value. Your story should capture the reason why you’re building it to highlight the business value.”

-“The other strand is around specificity: What are the steps for production?”

3. Start pair programming

At Pivotal, “pairing” consists of two engineers coding at the same workstation with separate mice and keyboards. The practice keeps them up to date with new features, pivots or unexpected challenges.

“Pairing actually lets you get into the flow more,” says Chan. “If you get distracted or interrupted by anything it takes you an hour to get back into it… We do it because it makes us go faster, and longer.”

4. Foster high-bandwidth conversations

Pivotal has focused on so-called agile development for more than two decades, where followers like Chan believe that software should be built as part of a team sport—with short, iterative feedback constantly being provided through customer crash reports or validation tests, for example.

“To build the right thing is often about communication,” says Chan. “If building the right thing is about communication then you probably want the highest-bandwidth conversations as possible.”

To accomplish this, engineering teams at Pivotal are located in the same area and typically there is no working from home or flextime. In fact, as Pivotal has scaled, the company has found the most efficient and productive moments occur when engineers work closely together in the same environment. Selecting the right tools has also helped during employee expansions. Chan’s team relies on Pivotal Tracker to rank (in real time) which tasks everyone needs to complete in priority order.

5. Utilize support

Collaborative tools may do little good if in-house developers aren’t used to designing on certain platforms. That’s where an external firm could come in handy. “The right partner can help with hiring and scaling,” says Chan.

Worried about getting over-dependent, or stuck with that partner forever? Familiarize yourself with a program’s codebase, how to run tests and the steps required to continue iterating after a partner is gone. “These are the things to think about when you’re doing your build out,” says Chan.

6. Implement core working hours

Pivotal employs other tactics as well to foster a more communicative, collaborative and ultimately efficient environment. While it’s not for everyone, the company enforces a tightly structured schedule with “core” hours where employees gather for breakfast. (This helps everyone sync to the same schedule, Chan says.)

Before coding sessions begin, project teammates update each other on what they are working on. Everyone then shares the same lunch break and goes home at the same time as well. Sounds simple, but as Chan notes, “this is very opposite to a startup schedule.”