Are you building an MVP using outsourced engineers? Follow these rules.
Ever wonder why so many outsourced software projects end in disaster? Or why you hear so many horror stories from friends who were excited to start something new only to spend a ton of money and time ending up completely demoralized. I hope my notes below can serve as a helpful guide in order to avoid a similar fate.
I have had the privilege of working with a range of different teams (from fully in-house teams to fully outsourced teams) and along the way have developed a few best practices when working with outsourced teams. Even more specifically, when using this strategy to launch a first version of your product.
This tends to be the phase of a company when it is most vulnerable and has the least resources, both financial and human, so any wrong choices tend to be magnified and can be the difference between progressing and dying.
You need to be Scrum Master AND Product Owner.
(This may violate the rules for Scrum purists out there so I apologize in advance.)
I’d be willing to bet that when most people are taking the brave steps of converting their idea into an actual working product, they haven’t ever spent time as a Product Manager or Product Designer. In order to fully appreciate the power of the Scrum process, I would highly recommend first becoming familiar with a few popular frameworks for start ups and product development. Two approaches that I often incorporate are Lean Start Up, first articulated by Eric Reis and Design Thinking, popularized by IDEO.
I won’t go into too much detail about these approaches (since thats your job), but they both emphasize a customer centric and iterative approach to problem solving which aligns very well with the Scrum methodology. In my opinion, this is pre-requisite knowledge to being effective. I learned this the hard way, but you don’t need to (if you are willing to take my word for it).
In spite of the fact that this has proven to be a highly effective set of development principles for many of the world’s most successful technology companies, I often see early stage founders and outsourced engineering firms engaging in a far more transactional and less collaborative way. The typical process often involves the founders generally describing what they want, some proxy product manager documenting that information into a work flow tool and then a few weeks later when the “sprint” is complete, reviewing the output…and inevitably everyone is angry.
No successful companies operate this way and neither should you. You need to insist that you are both the Scrum Master and Product Owner at this stage and be committed to writing user stories, daily stand up meetings and a far more involved and iterative process. If you or the firm you are considering working with are not willing to do this, I would highly consider rethinking the project.
Negotiate a Full Time Monthly Price Per Engineer.
This is another element of outsourced engineering projects that often leaves me shaking my head. It is all too common that founders get lulled into either price-per-project or hourly pricing models because they think they will save money. Conversely, these structures allow outsourcing companies to more effectively (I mean deceptively) win business. Next time you post a project on UpWork, ask yourself how anyone can make such a concrete estimate on cost within a few hours and without a detailed understanding of requirements. This is an obvious case of incentive misalignment. I have never EVER seen this work nor have I ever seen a project completed to satisfaction within the projected budget or timeline.
The most effective way for both sides to structure pricing is on a full time per month basis. For the founders, this has the essential benefits of being able to implement the scrum process, communicate often with your team, have far more visibility into progress and feel confident that your incentives are aligned with the development company. On the flip side, this allows the development company more clarity into their own resource allocation and also ensures them some satisfactory level of profit over a defined time horizon. Keep in mind that profit margin is not necessarily the key driver for an outsourcing company, but rather stable long term projects (as this reduces churn, lowers the number of new customers required to meet revenue goals and generally creates higher client satisfaction which is also a key new business driver in the form of referrals).
Don’t outsource UX.
Put simply, different cultures have different expectations on what type of user experience is deemed acceptable. They may also use different products which may not employ the same design conventions as you are used to. This suggestion is strongly related to getting customer feedback and embracing a scrum type approach but its important enough that its worth calling out on its own. If you are going to pay a premium at this stage, invest in a designer that you believe in or do this yourself.
Don’t Be Shy. Get Customer Feedback Immediately.
There is a lot that could be theorized about why people are so apprehensive to launch products that they don’t think are “ready”. Regardless of their reasoning, they are wrong. This is one of the most common mistakes of inexperienced founders…and can also cost you dearly in terms of time and money. In my opinion, a founder should be getting feedback on their product even before the MVP is launched. This can be done in the form of wireframes, splash pages to get data on marketing metrics, pre-selling, discussions with potential customers on how they might want to pay for a product, etc. This type of research is one of the major roles of a Product Manager. Through talking to customers, distilling and analyzing data, a Product Manager can gather the insights needed to continuously improve (a “Kaizen” approach as the folks at Toyota would say). A more structured way of describing this cycle is hypothesize, brainstorm, measure, assess and this should be done from day 1.
Taking leaps of faith on your own judgement that go untested over long time horizons or entire projects is a recipe for disaster.
Treat outsourced team members as people not resources.
Morale is important in any team. That includes people you are working with across oceans or on the other side of the world. While they may not necessarily share your passion for a particular project, they certainly will be a lot more excited about it if they like working with you and have a clear understanding of what is expected of them. This may sound obvious, but I’d say this is the exception, not the rule.
I’d love to hear any other suggestions or thoughts you have from your own experience.