Product Outsourcing – Getting the best out of your outsourced product development initiative!
[tweetherder]Startups (especially those that are first-time to outsourcing) tend to feel concerned when they are offshoring their product development[/tweetherder]. The intense collaboration required during early days of product development, gets intruded by distance and cultural differences. Process, Development philosophy play a hand in making the relationships fragile.
Here are some pragmatic ways to handle offshore product development team relations:
Stand up calls
Have Stand up
skype calls Google Hangout (clearer videos, remote screen sharing) in the morning. Talk about the progress made the previous day, and clear questions/provide clarifications if any. Make sure you get a brief about what your development team is going to be working on that day.
Just make sure that it does not become a mere ritual of snoozing off reminders. [tweetherder]The more you interface, the lesser you have to test / re-do later.[/tweetherder]
Project Management Tool
Have a project management tool like Pivotal Tracker, where you write down all your user stories. Having your user stories written down in one place is very critical. This is the one sacrosanct document. Everyone refers to this and basis their work on what is written here.
Tip: Add your attachments to your user stories. If you want your banner changed. Add the new banner here. If there are a lot of files, share the link to the Dropbox folder here.
Instead of debating on a tool, pick just any that your development team is comfortable with. [tweetherder]The best way to manage a project is to avoid emails[/tweetherder]. Unstructured communication without trace-ability is what you are signing up for with email-led project management.
The Agile methodology of software development is all about Feedback . As the project flows, you tend to communicate your concerns and modify/add requirements during the Stand up calls. Make sure that you add the changes to the project management tool. Remember that is the sacrosacnt document. I would encourage you to add clarifications/clear questions as comments on the user stories. This establishes the thought process on that user story throughout the team. This gives more flexibility to the development team, as no one will miss the context or progress.
Your app development team may not always be the one who leads the product development activity (let’s say you get funded and you can now build your own team!).[tweetherder] Context of what decisions were made, will go a long way to avoid handover disruptions.[/tweetherder]
Bring a story to closure / Delivery and Review
The status of every user story should be available in your project managment tool. Typically the user stories go through the following phashes
[tweetherder]Started -> Finished -> Delivered -> Accepted/Rejected[/tweetherder]
Accept or Reject a story within a day after it has been pushed to you. This keeps the developer from building on top of a rejected story and helps instant re-prioritization.
The first step in any project is to GET YOUR STAGING SERVER READY. This enables you to visualize the development of your project.
Review daily. Review as soon as your developer delivers a user story. The quicker you review the user stories, the quicker your project is delivered.
Create a sense of urgency and importance around deadlines
If you don’t have a launch date in mind and there is nothing that’s show-stopping if you don’t get it out on a set date, you are inviting procrastination. Set an external / uncontrollable deadline and communicate that you’ve vested to that deadline. It gets you and the team to the discipline of launching.
While time estimates in software development are never accurate, let that not be an excuse to not ship. Just as you launch your customers may lead you to what they want (which could be different from what you built). So be pragmatic. [tweetherder]Launch fast. Escape the guilt of ‘perfecting as a way of avoid customer scrutiny[/tweetherder]!’
Optimize for quality very early. If you understand code,review code regularly in the early stages. Give feedback on the coding style, the way the functions are named, the tabspaces. Is the code test driven? Developers spend more time fixing and optimizing code than writing it afresh. When you have found success with your early iterations and are moving towards a stable product, invest in engineering scalability – Test Driven Development is one of first initiatives you’d have to adopt!
Building a product is not a discrete one step activity as many entrepreneurs who outsourced, think it to be. It’s just the beginning of a long conversation with your customer base and the interaction would put your product to harsh usage that you have not planned for. So before you outsource, think beyond the first release. Think about continuous investment in engineering and build capacity to manage that process!