How to Avoid Over-Engineering Your MVP, from Remedy Point Solutions’ Oleg Krook

When you’re building your MVP, you don’t want to get carried away with technical complexity and advanced features. Labs mentor Oleg Krook (cofounder and CEO at Remedy Point Solutions) co-hosted a Labs session with Igor Moliver (RPS’ head of product), and Peter Stein (RPS venture strategist), where he spoke about how to avoid over-engineering your MVP. Krook focused on the need to involve engineers in the business value of the MVP and how this approach worked at ClassPass, where Krook served as director of engineering and led an RPS team. Moliver further explained this approach below.  

Your engineers need to understand the business behind the product

Krook encourages founders to put engineers in-the-know on the business side, “to understand what the goals are so that they can think in the same terms and make decisions that are going to support the business as opposed to thinking only about engineering,” Moliver says.

“If you let engineers go off on their own, they'll build something, but it may not be the right thing for your business,” Moliver says. “That’s a mistake a lot of early-stage startups make, particularly those that may work with an outside team to create their MVP. That to me is the number one reason for failure there, because it doesn't really matter if you build a beautiful product with a lot of features if it doesn't actually meet the user needs and isn't going to deliver the business the value you’re looking for.”

How this played out at ClassPass

When Krook was director of engineering at ClassPass, he led an RPS team helping to build out the company’s first mobile version of their product. “We worked with them to continuously add levels of complexity but in a measured fashion, making sure to deliver the business value first and worry about the engineering second,” Moliver says. “By doing that, we were able to put out a pretty strong product in about four months, and they were able to get it out before an important deadline before the holiday season. That allowed them to build a user base and raise a series A which in turn allowed them to acquire a competitor. By the time they were series B there was a bigger in-house team and they starting adding further complexity and moved to a more complex microservice architecture.”

“The engineers might have wanted to build something complex right away, but by focusing on the business value, they were able to advance the business in a way that made sense and allowed ClassPass to become a big company in about two years.”

This post is based on content from a WeWork Labs programming session.

Interested in connecting directly with this mentor? Ask your Labs Manager for help.

You've successfully subscribed to WeWork Labs Insider
Great! Next, complete checkout for full access to WeWork Labs Insider
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content. Check your email If you are not already signed in.