shutterstock_120012799
Articles

Canadian Startup MVP alternatives: Toronto’s Guardly, Waterloo’s Blackberry and NYC Dev Shop

In the world of tech startups, the minimum viable product (MVP) model has become something of a mantra. But is it really the best approach for everyone?

“When you (design) an MVP, the focus is to figure out what is the core assumption, or the core thing that is going to make this product a success,” says John B. Peterson III, partner and head of operations at NYC Dev Shop, a New York company that helps startups build MVPs.

So what are they? Say you wanted to build an app to find public washrooms in downtown Toronto; the MVP could be a simple map of washrooms within a small, highly-trafficked area. This would allow you to see if there was a demand for the product. If that was successful, you could begin adding more features, like a rating system for cleanliness, or expanding the coverage. The features that catch can be expanded while unpopular ones are dropped.

This lets business owners discover whether there’s demand for their product, and gives them a direction for its features, before they have to hire a full staff or pour cash into long-term product development. In other words, it can save a huge amount of money.

“(It’s) about getting a couple users and getting some feedback, finding out what people like or don’t like, and building from there,” says Peterson.

But the MVP does have it’s downsides, and there are other successful development models available.

Release early, release often – the best-known alternative

One of the most popular is “release early, release often.”

“This philosophy places strong emphasis on the needs of our clients,” says Conrad Wiebe, leader of development at Winnipeg’s Thinkbox Software, which develops visual effects and film editing software.

“Release early, release often,” calls for a more fully-featured prototype to be tested among a small group of users, instead of a bare-bones offering going out to the general public. This makes for a much tighter feedback loop between developers and potential clients.

According to Eugene Fiume, a computer science professor at the University of Toronto, this can help avoid one of the main problems with MVP — it always garners a lot of feedback, but that feedback is not always helpful.

“Iterations are really noisy,” he says, “the noise can really overwhelm the signal.”

But the approach does still allow for low-risk, gradual scaling and iterative feature additions.

“Essentially, both philosophies attempt to eliminate the risk of creating software that no one will use,” Wiebe says, which can be “a complete deathblow to smaller startups without a strong existing client base.”

Which model a company chooses depends largely on how they got their start. In Thinkbox’s case, the company began as an in-house development team for Winnipeg visual effects studio Frantic Films, before being spun off into its own business. This meant they started with a built-in customer base, making “release early, release often” a perfect design philosophy.

“The software was written to solve very specific problems and assist with technical challenges within the company,” Weibe says. “As the software evolved it became more general and attracted the interest of a growing client base.”

Tweaking the MVP: developing in parallel and being prepared to pivot.

According to Fiume, one of the issues with the MVP is that developers can’t always tell why a feature or product isn’t catching on. He says sometimes the problem has less to do with software and stems more from a company’s business model.

“MVP doesn’t necessarily address the question of whether the features are right,” he says, adding that a business can handicap good software with a bad release or marketing strategy.

When this happens, he says, companies can sometimes find success by targeting their product at a different market or changing their payment model.

“Do the pivot — you’ve got this working system out there, not getting traction,” he says, “so try to see how you can redeploy the features and the technology into a different space.”

According to Fiume, there are three main business models for applications. While the ad-based model is the most popular, it does require a large audience because the price advertisers pay per-click is fairly low.

The other models involve users paying directly for apps — either through a “freemium” model, where customers hand over cash for additional features on a free-to-use program, or a fully-paid premium model, where customers pay up-front.

The “freemium” model is gaining traction, Fiume says, especially with narrow-function apps and online games, where companies can up-sell their users.


Premium apps are a different story.

“There is still relatively low appetite for fully-paid up apps,” says Fiume, but he expects this to change in the future.

And while many startups focus on the consumer market, he says it’s important for developers to remember other options, such as business to business programs.

Toronto-based Guardly made this switch. The company launched a consumer personal safety application that calls 911 and texts emergency contacts with a single touch. The product did okay, but wasn’t as scalable as the company wanted. In order to keep growing, Guardly developed enterprise solutions, including a web-based incident management system for campuses. It has been adopted by OCAD University, where the app is free for students and integrated with campus security.

Fiume also points to BlackBerry, formerly RIM, which attempted to move from the enterprise sector into a more consumer-focused business. While he says their pivot attempt in 2005 “was largely seen as a failure,” he has higher expectations for their new offering, BlackBerry 10.

He also warns that a pivot isn’t without risk, and can sometimes lead to a loss of staff.

“Software engineers might say ‘that’s not what I signed up for,’” says Fiume.

One way to avoid this situation is by developing in parallel, either by testing multiple features – or different business models at the same time.

“Multiply the MVP,” says Fiume. “Try a lot of things and see what works.”

This could mean having sub-teams within a company develop and test different features or launch slightly altered versions of products for different markets. This increases the chances of a startup finding a product that sticks, but also comes with increased costs and development time, making failure more expensive.

Is avoiding risk that important?

Avoiding risk is one of the reasons that Jonas Brandon, cofounder of Toronto-based Startup North — a website that features an advice blog written by entrepreneurs, along with job and event listings — advocates the MVP approach.

“It provides a framework for reducing risk by focusing on what matters at every stage of development,” he says.

But Fiume says the entrepreneurial approach to software doesn’t always work, and large companies do occasionally take big risks for big rewards.

He points to Amazon, which made a huge bet when it transformed from a simple online store into a full e-commerce platform. The company’s sales have increased from $3.12 billion in 2001 to $61 billion in 2012 as a result

Plus, no development model can completely eliminate risk.

“Every startup takes a big risk,” says Fiume, “It’s an uncertain world out there.”

Advertisement