1st Team | The Tactical Guide on Finding & Working with Development Partners Overseas w/ Tintash
1st Team | The Tactical Guide on Finding & Working with Development Partners Overseas w/ Tintash
Subscribe to get the latest theses and insights from 650+ VCs every Sunday
Led by a team of Stanford, Apple, and Paypal alumni, Tintash is a software development firm that offers clients managed remote engineering teams from around the globe. They design and build digital products from scratch and can also augment existing engineering teams
The company has grown to over 200 employees and has worked with a notable roster of clients across industries, including sports betting giant DraftKings, mobile game developer Stick Sports, blockchain company Stacks, Bed Bath and Beyond, and dozens of others. The firm’s clientele range from startups at the earliest stages to Unicorns and Fortune 500 companies.
In this post, Faizan Rasool, VP of Marketing & Sales at Tintash, shares tactical best practices for finding, vetting, and working with overseas development partners. A special thanks to Mannan Amin and Aiza Yasir for their assistance with this post.
Tintash is one of the firms that came highly recommended by founders through our 1st Team survey. If you’re looking for an engineering partner, fill out the form through the link below and let them know you heard about them from SandHill.io!
1 – What materials or research would you recommend a startup pull before engaging with a development partner?
The answer will depend on what stage the startup is at. We see 5 stages during a startup's journey: Discovery, Investor MVP, Goto Market MVP, Improving Product-Market Fit, and Long Term Growth (also shown in the table below).
If you are a startup in the earlier stages then you should start by answering some questions to get started on early customer validation which will also help with the prioritization of your MVP feature set. These include:
Who is the customer of my product? Try to clearly define an ideal customer archetype here.
What specific problem do I want the product to solve?
What is the core experience my customer needs to solve their problem?
Are there any competitors in the market that are already doing this? What are their most used features? Any pain points in those key features?
When do I want to release my product? Why is this timeline vital for me?
We’ve seen founders come to us to kick-start product development but they haven’t given thought to some of the above questions. This can lead to a delayed kick-off and can create roadblocks during product development.
At the same time, it is important to understand that you can’t have complete clarity in the earlier stages. You will get there iteratively by building and testing MVPs. However, at least going over these questions and writing down assumptions saves time getting the design and engineering team on board toward the vision of your product.
We’d also recommend understanding what is important to potential investors. This will help guide the building of an investor MVP (what we like to call the MVP at this stage) to test early customer validation.
In later stages, it is more about understanding that improving product market fit is a journey. To begin with we recommend the superhuman product market fit approach to have a way to measure progress and to figure out which features you’re going to prioritize in the next iteration(s).
For non-technical founders, it really helps to have a technical advisor or friend to help build trust with the engineering team you choose. For example, they can help validate at the ballpark level scope-time required, which helps build confidence / trust with the tech team.
Usually closer to the growth stage the team has decided on tech stacks, project management tools, work times, and culture which help select the right engineers to augment the team with.
In terms of books and materials we highly recommend:
The quick talk on systems thinking TED talk by Tom Wujec,
The superhuman product market fit article.
The book, “Don’t Make Me Think” by Steve Krug
2 – What is your general recommendation to startups on whether to go with a fixed cost or flexible cost arrangement when working with an overseas development partner? Does it vary for startups vs. corporates?
We feel the overseas part should not change the best approach required to set up your startup for success. Fixed cost is generally not the way to go since it implies fixed scope/features which hurts because the nature of a startup requires evolution on what is to be built the minute you have a better understanding of it with market interaction. Additionally, startups have engineering unknowns on the product roadmap. If these unknowns aren’t there then a fixed cost model may work. However, with any unknowns, the development team will be taking a risk with a fixed cost commitment.
However, we do understand that funds are always limited. The approach we recommend is to have a clear set of priorities for what is to be built/improved and tested in the next iteration(s). Then see if the partner team can commit to building it all within the given funds. If not, then you must further reduce the scope. Often engineers may be solving things in certain detail which is not required for the early validation phases a founding team is looking for to get the next round of funding.
Even for larger companies, budgets for projects have limits and hence should follow a similar line of thinking. Else you risk building something that may not be a requirement of the next stage of market interaction/testing.
Thus, overall our recommendation is to think about what are the biggest (un)knowns that can have the biggest impact on the success of the product and build those to test out the market..
Another way to think about fixed vs flexible is what risk you are trying to reduce. Do you only want something built within a certain budget or do you want the right set of incremental features to be tested in iterations given your runway. A team working with fixed costs for a scope will be stressed to complete your project and move on to the next one. They will not be motivated to spend the time with you to understand what are the most important elements to build or tweak to test next.
3 – What are some common challenges that arise when working with startup clients? Any advice on how to manage these challenges?
There are many challenges that arise. I’ll share the three main ones:
The biggest challenge is managing expectations with founders. The reason is planning fallacies that somehow become an inherent part of founder expectations. We’ve learned the hard way that we need to help founders plan for not only the best case and worst case scenario but also to expect that the initial iterations will land you somewhere in between.
The reality is that turning a startup into a success requires several pivots and iterations before a product-market fit is achieved, and even after product-market fit is achieved, the journey towards a growing business requires making numerous other adjustments.
Planning fallacies are best described by the Nobel Prize winning author Daniel Kahneman in his book “Thinking Fast and Slow”. He talks about how those who are executing an idea can indulge in delusional optimism and assume that only the best case scenarios will play out in the execution of their project, rely too much on their own calculations of how much time and effort it can take to execute something, and can ignore the outside view of experts on the time, effort and cost other similar projects have incurred in the past.
The second one is not having a clear understanding of the product vision, its core functionality, and what problem they’re trying to solve for their customer. This requires spending time in discovery where we can help unravel different use cases, create visual references, get an idea about technical unknowns, and overall lock the initial scope of the product.
Third, not considering the product/development team, their team. You know the popular saying that “culture eats strategy for breakfast”. Startups need a highly engaged team culture.
Founders must take time to not only share their big vision with the development team but also explain why and how the next iteration/problem they are going to solve will have a big impact. The team will usually respond by taking a lot of ownership and everyone is surprised by the magic that happens.
4 – It sounds like, in addition to development, Tintash often helps clients with other aspects of product strategy as well. What do some of these other processes, such as Discovery, look like?
The goal always is to enable our client to be successful in evolving to the next stage in their product evolution and overall startup journey.
As mentioned earlier, if a customer is very early in their journey, then we start the engagement with a Product Discovery stage. This helps define product goals, understand the customer archetype(s), map out user journeys, create low-fidelity wireframes, define a brand language and incorporate that into polished mockups. Additionally, we are able to run tech due diligence, identify unknowns, and figure out an engineering scope plus ballpark estimates.
In the scenario where a customer comes to us at a stage where they already have the development requirements sorted out, we still do a due diligence exercise with them. This helps to ensure that we as a development partner have a strong sense of who the end-users are for our customers, what value proposition our customer wants to bring to the customers through the product they’d like us to build, and how the requirements they’ve already gathered will enable their product to deliver intended value to their customers once developed. We do this exercise to enable the assigned team to understand the why behind what needs to be built. In almost all cases, this due diligence exercise helps in further refining the requirements, which helps ensure that we use the precious runway available in the best possible way.
5 – Startups are often under pressure with the limited runway. Any recommendations on how best to work with a development partner, especially in a flexible arrangement, when your runway is constrained?
It is imperative to ensure that every bit of runway is used in the most effective way possible. This requires that everyone involved in the project should consider themselves to be a part of the same team. When it comes to delivering a product with limited runway, there is no space for an ‘us vs them’ mentality. Our leadership team is regularly working with our customers and their teams at Tintash (we refer to them by the customer name) to make sure that this cohesion exists on all of our projects.
Coming together as a single unit enables everyone to get onboard and have a common understanding on the overall product goals, the available timelines and budget in which they need to be delivered, the milestones/work increments that need to be achieved, and the quality at which they need to be delivered. This of course requires transparent and consistent communication on the above mentioned aspects.
We’ve been able to effectively use a modified version of the scrum model to ensure that the work process retains the agility a startup needs to respond to quickly changing scenarios while making sure that there is a tight handle on scope and budget. There are two main aspects to this model that we follow. Firstly, there should be a defined work cycle/sprint, and then second, the milestone/work increment should be delivered. The scope of the work increment is decided at the start of the work cycle through a sprint planning meeting, and then the work increment is delivered at the end of the cycle through a sprint end meeting. Sometimes the two meetings are combined into one. The goal is to ensure that usable software is tested and delivered regularly. The teams also meet on a daily basis to regularly review progress across the work cycle.
Additionally, the leadership within the team needs to come together every two weeks or four weeks, to evaluate what product goals have been achieved and what budget has been spent to keep a tight handle on budget and scope.
6 – Do you have any advice or tips for how a startup should go about finding and evaluating an overseas development partner?
There are two parts to this: Finding the partner and Vetting them.
For finding, look for referrals from your network, and go through listings like Clutch.co (such listings are sometimes sponsored so sift through carefully). We recommend talking to a few companies to get a sense of the landscape.
For vetting, go through their sites, decks, and where possible try out some of the applications they have worked on recently.
Next, talk to the team that will be assigned to your project. All teams are not equal in any company (we believe!). If you're not technical, have a tech expert friend talk to them and rate them on the required skill sets.
And lastly, we actually recommend prototyping the relationship with the development team. Carve out something small and work with them. See if they can prove the tech abilities needed and are a good work-culture match for you. No team will be a complete match in the beginning but each early sprint should get better in terms of communication and delivery.
7 – What is the best way for a potential client to inquire about working together?
What a great question! Ping us on our contact us page on our website and do mention that you read about us in this article. It’s a simple, short form that takes a minute to fill out. Our customer success team will follow up shortly!