Outsourcing 101 Part 1 | Mark Stoner

I'd also like to introduce Mitesh Bora. He's the president of InfoBeans. InfoBeans, 16 years old. Not me, the company. So I don't know, whenever anybody says you're an expert at something, I kind of have to go, well, maybe not. So what we're going to talk about today is outsourcing. From what I understand, when we started kind of this discussion with Draper, It's kind of a challenge to figure out what— how to go from A to Z. Let me start out by asking, how many people consider themselves non-technical founders? Okay. Okay, so that's about half or so, so that's good. You get the A or the B presentation that way. Technical founders, that's— Mitesh is an engineer and he's going to get into more of the meat of it and so forth. So what we're going to cover today is just a general outsourcing overview, MVP product development. How many weeks into class are you? 2 and a half. 2 and a half. 3rd week. 3rd week, okay. So you're probably just getting into the MVP product development and so forth. And then, yeah, if you have any questions that— if I say anything interesting, just holler. Otherwise, we'll kind of run through this. And then for the agenda today, I'll give a talk, kind of go through a few slides and so forth. Mitesh is going to kind of interject or kind of talk more on a technical level, and then we're going to listen to your pitches. So we have a certificate, so the pitch winner wins 20 hours of free consulting time, help writing specs or whatever web development, mobile development you need. So we'll talk about that. Non-technical founders, I mentioned, making requirements clear. Potential issues as far as communication, payments, product, work quality, and transfer of work, and then legal issues. So Infobeanz, it's a 700-employee software company publicly listed in India, offshore provider, web mobile application development, business process automation. You see our areas: business, custom business application development, Quality assurance and automation engineering, UX/UI, so user interface, user experience, and big data, which is obviously huge right now, just all the activities in that area, fintech and so forth. So the engagement models, how we work with different clients, and I just want to make this as useful as possible for you, kind of how to go forward. So the first way we work with people is under time and materials. So time and materials is if the specs are unclear, so early stage, you're kind of working through what the process is, what you're going to build, and so forth. Time and materials is an hourly rate plus any expenses if there's travel and so forth. So that's the simplest way, but that's how we work with most people. Our largest client in the Valley, we have 80 people working on offshore. Another client, we have 110 people. Both of those companies started out with one person, expanded to 2, a whole team, and so forth. Fixed price is if the requirements are clear, if you have exactly what you want to do. Certainly for larger clients, we can give a fixed price, a bid basis. Offshore, most of our people are in India. Headquarters are about an hour south of Mumbai, a town called Indore, where Mitesh is from. Onsite, we also offer onsite staffing as needed. And then dual shore. Dual shore is where we have an offshore team, but we might have an onsite project manager. So as projects get bigger, relationships with companies where they're the ones that are actually managing the team in India, and they're going through the agile development or whatever the process is to work with a local team. Top reasons for outsourcing: reduce costs, focus on core services, improve quality, increase speed to market. It's much better obviously to have kind of people across the desk from you. If you've got a team of people, it's more efficient, but certainly kind of early stage and then the cost of talent in the Valley right now, it's hard to find that talent. Foster innovation, access new skills or technologies. We run into that a lot where people are just looking for a different skill set that we can provide. Most frequent causes of outsourcing failures: buyer's unclear expectations, poor process control, poor communications is a lot of what we run into. You really need kind of weekly contact, what's going on. Weekly project meetings, the same as you would in an office. But we don't really find it's that much of a difference in communications other than the time difference, say from San Francisco to San Jose. You just have to set clear expectations and so forth. Providers' poor performance happens, interests become misaligned. Sometimes the great thing about a startup is that it's iterative, it changes and so forth, but You have to make sure everybody's on the same page going forward, what the business direction is, what the value proposition, if there's any changes. Where do we start as far as product roadmap? Where you're at right now, probably. I read through, it was interesting, your directories. Great, a lot of international people here. I lived in Paris for 3 years, worked for France Telecom, worked for the British government, worked for a Japanese company, working for a Indian company now. So you're probably working through the business model canvas. I think it's a great way to, very succinct way, what are your, what's your value proposition, your costs, etc.? Who's the customer? Customer discovery, user personas, questionnaires. Solve one problem at a time. Sometimes I run into that with startups, they're trying to do too much. You just have to focus. And what is the one issue, what is the one problem you're trying to solve before you do anything else? Clear specs up front. We work with several companies. One guy, VP of sales, had a great background on the sales side, but he wasn't sure how to take his concept forward. We started with him with a PowerPoint presentation. Another person we've been working with didn't really have any background at all. She just had an idea, and we've been working with her. So we just kind of get what are the specs, the nice-to-have or required specs, nice-to-have if you have funding and so forth. And the time upfront reduces cost and pivots later. In other words, the sooner the better you can define what your startup is, what your opportunity and so forth, the less backend time you're going to have for change and cost. And I do— I'm leaving a copy of this presentation if anybody would like this later. Again, where do you start? Infrastructure, database, language. Mitesh can talk about infrastructure, kind of what you start with. A database is critical, kind of long-term. What language? Is it Python, Ruby? Why do you pick one versus another? Deliverable milestones by phase. So if you're working with a third-party provider, Try to break it into bite-sized chunks. What are you getting? When is it gonna be delivered? Is it based on, okay, they get login access, or break it into smaller pieces. You can also control kind of how the work they're doing. You see what their timeline is. But also it leaves, you know, there's an opportunity to break it off if it's not happening for you too. Be clear on the financial model. Everybody has great ideas, creative process and so forth, but sometimes the financial model is a great way to just look at it very practically. How many units you're going to sell, what's the price, and when you cross-reference that, you think, well, okay, they're not going to pay X price and what's the margin and so forth. How many steps to revenue? You need to monetize as soon as possible. So as you're building out your app, your mobile app, your website, just think, If I click once, twice, 3 times, call to action. You need to monetize as soon as possible. Feedback from family and friends is great, especially in the early stage. You might be worried about your idea, getting feedback from people you know, but also you want people to tell you that it's terrible or I don't get it. The sooner you kind of get done with something if it's not the right the right startup or idea or whatever, and the course correction, the sooner the better off you are. Non-technical founders. My background is really sales and marketing. Worked for Accenture, PricewaterhouseCoopers, France Telecom, so kind of a consulting background. I sold enterprise software, but I don't know how to code or that level of detail. But it's really, I mean, I renovated a 1910 Edwardian house. You just have to ask the right questions, whether it's construction, building house, renovating, every other field, you know, you can, you can do it. What is the goal of the MVP, the minimal viable product? Is it to generate users, subscriptions, revenue, or just to test the concept? So maybe if it's under a $10,000 price tag, maybe it's a throwaway. $20,000 or whatever. That's kind of your determination. Other things you might look at is buy versus build options, meaning maybe there's another way to do it where you don't have to build everything from scratch early on. Look at companies, and I'm not sure if I'm pronouncing it right, Zapier. They do a lot of connection between different applications. If you have an idea, Google white label and see what comes up. Maybe there's some way you can white label a product just to get into the market and test it out. APIs give you access to maybe a new area, especially like financial services, fintech. It's very expensive as far as compliance, so there's a company called Yodlee. There's several companies that will get you into that market without having to develop it. Also look at open source projects, source code, Creative Commons. Maybe there's some other ways that you can structure kind of early phase product development MVP. The other thing about finding open source projects is you might find a developer with some experience in your area that's put something up there or that you see what they're doing and you work with them going forward. The other thing about from a non-technical founder perspective is just you can start at this stage, move a business forward. Obviously it's better if you have a technical team and you certainly generally will not get funding from a VC unless you're farther along and really have a technical team and infrastructure. But I'd recommend hiring them as a contractor before making them co-founder or CTO or strike up a deal, whatever. To be joined at the hip if you're not sure if it's going to work out might not be a good idea. Obviously equity, if you need to do that kind of early on, you might find a great partner though and move forward, but I'm just cautious to spend 3, 4 months working together, kind of get a sense that you're on the same page. It's much easier if you can draw everything, draw it on paper, draw it, send them designs and so forth. The clearer you are again on where you're going, what your vision is, the easier it is for everybody. Make it as detailed as possible and simplify it. People come from startup ideas from different ways. Some are just storytellers and talk it through. This is another idea if you're familiar with concept development, mind map or flowcharts. This is a website, Coggle. As you see, coggle.it. So this is a mind map. You can use this for flowcharts, for homepage directions, and so forth. Another one below it, Gliffy. Another way sometimes we see people working is from the wireframes. Some people are better— I teach a class about it yesterday, about Mosaik. Oh, really? Yeah, it's a pretty— it's a good website. So the idea with this is just some people are more visual. They want to work from a homepage. They start with a homepage. If this— you push this button, where does it go? And this is more visual. And then really the third way I mentioned, the financial model of units, process, break it down that way before you come here. So people with different skills come at it from different directions.