Building successful MVP with offshore team. Part 3.

This is part 3 of the Building successful MVP with offshore team.

Remember – the more details you let the developer interpret freely and assume, the more likely you are going to fail. Think about it this way – if you decide to build your own house, will you tell the builder that you would like to have a gorgeous open floor plan house with 4 bedrooms? I guess not. You will go through each detail of your dream house before any construction starts.

Product manager

Product manager converts your vision of the application into the exact specification of what user will experience. This includes the exact steps of how a user navigates through your application, mockups of each screen, any data validations and so on. The key word is “exact”.

Let me give you an example. It’s not enough to tell a developer that you need a Log In functionality. You should provide the exact details about it:

  • Should it accept email and/or username
  • Any restrictions about username and password
  • Error message if Log In fails or any field is missing
  • Should user be able to stay logged in (Remember Me option)
  • Should log in ever expire
  • How you are going to handle “Forgot my password”
  • and so on and on …

But this is too much work to describe all these details. Shouldn’t developer already know all these?”. No, but he will assume, and that’s not what you want. Believe me, you will do this work anyway. It’s just a question whether you will do it upfront or after the coding is done, the result is not what you need and it should be rewritten. Doing this work upfront saves you time and money. It also gives your QA the exact testing plan.

Now the question is how can you nail all these details upfront? It’s not that difficult, just don’t try to invent a bicycle. Find any popular application that has a similar functionality and check how it works. For our example with Log In, you can try Facebook, Gmail, Instagram or Quickbook. Try all possible scenarios, write them down, apply for your own case and pass them to developer and QA. You should discuss this specification before any development is started. Make sure that it’s very clear for developer and QA that they should not assume, but ask.

Be proactive and you will succeed.

Building successful MVP with offshore team. Part 2.

This is part 2 of the Building successful MVP with offshore team.

What is MVP?

Let me define what I mean by MVP before going into recommendations. MVP is a product with the least set of features that founders can use to test their business model. You have to consider whether it’s a throw-away or a foundation for your real product. Most founders start MVP with a throw-away approach in mind. They would like to build something quick & dirty and test with a few clients. They plan to build a solid product if MVP has some traction.

It doesn’t work this way in most cases. Founders continue building on top of the throw-away MVP as soon as they get some traction. And soon they have a code that’s difficult to maintain and grow. Their application doesn’t scale and performance is bad. And sooner or later founders face a taught decision – invest into rebuilding the product.

It should not be this way. It’s possible to build a prototype without any investment at all (I am talking about cash, not time). You can do the UI in Sketch and test the UX in InVision. These are very valuable tools that any founder should consider mastering anyway. BTW, I discourage a common theme on startup forums- learn how to code. Programming is not easy. It will take a lot of time to learn it to the level where you can produce something beyond “Hello, world” application.

Originally published at

It’s possible to build MVP on a solid foundation that will be a “keeper”. And it does not need more time or money to build than a throw-away product. I’ll be describing how this kind of MVP can be built.

Developer is not enough


Steve told me: “If only I could find a good developer …“. If you also think that the “right developer” is the way to success, sorry, but you are wrong. If you think that you can pass your vision to a developer and get it back as an application that is close enough to it – forget about it. Save your time and money.

To build a good MVP you need:

  • Product Manager – translates your vision into actual product behavior
  • Project Manager – triages the work and makes sure that it’s done on time
  • UX/UI Designer – defines the experience that users get from your application
  • Architect – makes sure that the “foundation” of your application is good and you will not have to throw it away later (optional, but …)
  • Developer – writes code
  • QA – finds the bugs and verifies the fixes

If you find a developer who can wear all these hats – great, but it’s not going to be cheap. Now, you can hire people to do PM, PrM, UX/UI, QA. Or you can do it yourself. In any case – there ain’t no such thing as a free lunch – you will pay for this work with your time or your money.

I will share how you can do all these work yourself in the next posts (it’s going to be more practical).

Building successful MVP with offshore team

My friend Steve (not a real name) called me recently. He would like to launch a business. He has an idea, business plan and some money to build an MVP. His question: How to? Steve cannot afford SF BA developers. His option is to go offshore. But he heard a lot of scary stories about working with offshore developers.

I’ve heard them too. A lot of them. People had a very bad experience. They will never deal with developers who are not with them in the office anymore. It hurts, I know. I would feel hurt and furious if my personal money were on the line.

But I’ve built successful high-quality applications with offshore teams. And the cost was a fraction of what it would cost to build in the Silicon Valley. I’m not the only one.

I gave Steve some recommendations. I will share them here in the next few posts. Steve can build his MVP offshore. He can do it fast, on budget and without a stress. These recommendations may be useful for you too.

Stop using Slack


Confession – this is a flashy title to attract an attention. Slack is a great tool and you should use it. But, please, STOP abusing it.

Let me explain my point of view. It’s a great tool to have a conversation with your team members. But it should not be used to preserve the knowledge. What knowledge? Anything that related to your work like discussions about product features, roadmaps, decision points and so on that you may need to reference back in the future.

Let’s say you have to discuss a specific feature of your product. I assume that you already have it tracked in one of the applications like Trello or Asana. It’s so tempting to just jump into one of the Slack rooms and start the discussion there. But unless you have a room for each features, bug, task don’t do it. And, no, I don’t advocate to have a room for each working item you have to discuss. Instead of going to Slack, find this item in the tracking system that you use and discuss it there. Your discussion is the knowledge that you would like to preserve. It can be useful for you in a couple of months or for your teammates when they will need it later. One item – one place to store everything important about it. It makes much easier and faster to find information when you need it.

Have you ever came back from vacation to find your Slack room full of unread messages? No? Well, I guess you don’t use Slack then :). How can you get up to speed with any decisions that were made about a particular task? Search? Read all the messages in a particular room? But it has discussions about 10 other items, all “shuffled” and polluted with totally unrelated chatty messages. But if that discussion is kept with an item itself in the tracking system, then you will get what you need right away.

Are you a manager? Then you have to track all work items of your team. But you don’t have to track ALL of them right away. Some need your attention right away, but some – can wait. You know that there is a discussion going on, but you don’t care about it right now. You will deal with it later. But when the time will come, you want to get up to speed fast.

So, do use Slack. But keep your knowledge where it belongs – with your work items. A small effort to put the information where it really belongs will go a long way when you will need it.

Urgent vs delayed

Another disadvantage of Slack comparing to email + IM is no explicit sense of urgency. In most cases, when we receive email, we know that we can reply later (unless it’s stamped as urgent). But when somebody pings you via IM, it means that there is a need for an immediate reply. Well, this is how it is in most cases. And this is not very clear with Slack. Unless you read the message, you don’t know whether a response is expected right away or it can wait.

This is not a big deal, because it can be easily fixed with some tag or “stamp” of the post. Just agree with your team what it will be.

And remember, a tool only as good as the user.

Happy collaboration!

Better TODO comment

Here is a simple trick that makes TODO comments more efficient. You have seen TODO comment like this all over the code:
//TODO: convert to prepared statement.
var query = 'SELECT processedDateTime FROM ProcessedEvents WHERE hash = ?'
Yes, it’s good to have it. This is a way to track a technical debt. And here is how it can be much more useful:
//TODO: vvs p2 convert to prepared statement.
var query = 'SELECT processedDateTime FROM ProcessedEvents WHERE hash = ?'
Just 2 small pieces are added:
vvs – your initials,
p2 – priority (p1, p2, p3)
Now, you can search the whole code base for your own TODOs (or TODOs created by a specific person). And when you see a comment like this there is no need to go to Annotate or Blame to find out who has left it (save time).
When you leave a TODO comment you are in the best state to analyze the impact of the incomplete work. That’s why putting a priority at that moment is so crucial.
It’s a simple trick that can save you tons of time, especially when you manage a team and do daily reviews of all commits.

Effective multitasking tip

I’ve been working on multiple projects recently. I’ve been managing multiple work projects effectively for a long time. I’m talking about working on multiple projects outside of my job. I am pretty busy at my work. In addition I do an open source development project. I’ve started this blog. And I’m developing one more application that is very important for me.

My normal day goes like such: wake up early, do some development for one of my personal projects, work on a personal project during commute to work, do my job, commute home and work on one of my projects again and may be some coding after dinner. I love my personal projects a lot and it gives me enough enthusiasm to keep this schedule.

Juggling job and personal projects was challenging for me at first. And that’s where I’ve developed this process that I would like to share:

Every time I’m going to stop working on one project and work on another I record what I was doing and (even more important) what I have to do when I resume working on the same project.

E.g.: fixed 80% of the bug #347. Finish bug fixing and update unit tests.

Simple? Yes. But it makes switching from one project to another less painful and increases productivity dramatically. It helps to get into the interrupted project much faster.

I’ve also realized that the same trick can be used in the office as well: if my development activity is going to be interrupted by a meeting I write down: was doing this, start with this after the meeting.

Try it and maybe it will help you too. Or maybe not. It depends.


oDesk is a great time-saver. You know what oDesk is, right? It’s a site where you can hire somebody to do some job for you. Some job that can be done remotely, like code writing, web site creation, QA-ing your code, editing your blog post. Go to their website and learn more about what kind of help you can get.

But, why would I hire somebody when I can do it my self?. I can edit my blog post. I can create web site. I can test my application“. It’s a question that doesn’t have a single answer: what is going to be – time or money? Sometime it’s money, and in this case you test your application yourself before launching it to your customers. But, sometime it’s “cheaper” to pay somebody to test it so that you can concentrate on something more important. I’ve just recently read a comment about a person who was gladly hiring somebody to do a job that would take him only an hour to do, even it would take a hired person 8 hours, because at the end of the day it was “cheaper” in a long run. So, sometime you can “delegate” something to somebody else and this way free your self for more important tasks (including spending more time with you family or exercising more, or just doing nothing and recovering after a tough day/week/month).

I’ve first heard about oDesk site in a book about Micro ISV. So, when I needed to build a team for a startup (with limited resources), I’ve turned to oDesk. And it was very successful experience. Not without challenges, but successful. Not only I’ve had people from around the world helping me to build a new product, but I was paying a fraction of what it would cost me to have a local team.

Ok, I hear you: “Another advertisement of a cheap offshore job market. Give me brake. You don’t know what your are talking about”. Well, as a matter of fact, I do know. Because I did it, with success. And I’ll follow up with what helped me to use offshore team effectively. Note that, offshore teams may not be an option for you – one of my friend who is CEO and founder of his company told me that in some cases (when the software will be used in a high-level security areas) it’s not possible to hire people outside of US. But I think it’s more an exception than a rule.

So, does it mean that the only way to use oDesk is in case of a business? Not at all. You can use it for some personal projects as well. Just remember that you pay you $$$ for your time, time that you can spend with your family, grow you skills or just relax. You can always make some $$$, but you can never buy some extra time. Unfortunately.

And here is how I’ve used oDesk for my personal need. I’ve had this WordPress-based blog hosted with another provider. It was free with my domain hosting, but I was not happy with the performance. I know, that it doesn’t really matter because nobody reads my blog :), but still I was unhappy. So, when Microsoft introduces WordPress hosting on Azure (I was doing a lot of development on Azure that time), I’ve decided to switch (BTW, the performance is much much better on Azure). So, did I know how to transfer my WordPress blog from one provider to another? Of course, not :). Can I do it myself? Absolutely. I can learn easily (there are tons of blogs about how this can be done). But, before moving on, I’ve decided to check what it would cost me if somebody else do it for me. After a quick search on oDesk I’ve found a nice guy in India who can do it for me under $50. So, what’s it going to be: $50 or a day of my life? It was a very easy choice for me (your mileage may vary :)). A few days later I’ve had my blog transferred to Azure. Yes, I’ve spent a little bit of my time to help the guy (just sharing some details, providing credentials for him and doing some securing clean up after the transfer), but it was much less time if I would do it myself.

So, next time when you need something get done, may be oDesk is you friend 🙂