We've all read the lean startup, so I won't rehearse the arguments/gospel in any detail here. I think its fair to summarise the whole thing by saying that the holy grail is to be 'data driven'.

In a lean startup world we should all be making product design decisions based on proven or disproven hypotheses inferred from data about how customers are actually using your product.

This is the smart way to do things for for sure. Being data driven is pretty easy when you have hundreds or thousands of users. But what if you are just about to launch your first MVP and therefore have zero data? How do you go from zero data to at least a bit of data? And then, once you have a bit, what do you do with it?

Here's some answers to these questions that I've drawn from my work. Please note, I'm very new to this, and not a maths or data or research guy (my background is design), so if this seems like 101 its not for you - this blog post is for people like me a year ago.

1. Infer some data from other services

It's almost always the case that you are doing something that is a bit like what someone else is doing, so you should try and benchmark your future data against theirs where possible. You probably did some 'competitor analysis' already, aka looking at other people's websites, but try and dig a bit deeper to get a sense of what success is. Some simple measures you can get for free:

Google trends. This is a no-brainer - go and search for terms / companies that are like your product to see how they are performing.
Keyword popularity / cost. Use your adwords account to see what the paid search popularity is around your product category / competitors.
Social media metrics. - Crude, but still useful. How many followers do they have on twitter? Is their blog attracting comments? How many FB likes do they have?

2. Do qualitative research immediately

There really is no excuse for not going and getting some qualitative data as quickly as possible. This is basically market research 101. Two things you should definitely do:

Interview potential customers. This is the core of the 'customer development' methodology, and I think its much better than focus groups or more elaborate qual methods. Just sit down with / Skype potential customers and do a simple three stage interview, starting with general questions about how they feel about the space you are in, following up with more focused questions about how they achieve the goals that your service helps people achieve, and then ending with direct feedback on whatever you have.
Do gonzo usability tests on your prototype. Again, very simple. As soon as you have anything vaguely presentable, even if its just a clickable pdf, do a sit down usability test. Ask your potential customer to just 'do what you think you would do' and see what happens,

3. Get basics 3rd party tools in there from day one

From the moment you get any traffic you want to know what's going on, and, although your assumptions about what to measure and what matters to users will be wrong, you still need to measure as much as you can. At Makeshift we use these tools in all our hacks - now we've moved into creating full products we're starting to build our own analytics tools, but to begin with you should just add these apps:

Mixpanel. Dead simple time series analysis, conversion funnel creation and cohort analysis. With you MVP you'll find that the data is very lumpy and patchy, so the most useful thing is generally the funnel until you get regular visitors.
Intercom. This is a genius service. Intercom turns visitors into real people by integrating with your sign up process, and then you can manage all your support requests and transactional email in one place. You can also feed user IDs into mixpanel so you can actually see the specific journeys taken by high value users through your site. Its so good its almost creepy.
Google analytics. Sure, the interface is horrible and its bloatware, but Google Analytics does do a few things well, in particular detailed info about traffic sources and good visualisations of your users journeys.

4. Keep going with qual post launch

Its easy to get caught up with looking at dashboards and running reports once you start to get a trickle of traffic, but you should't neglect the most inspiring form of data - qual - during the first few weeks. After you've launched I suggest that you re-do the qual activity you did before you launched, with an extra focus on trying to get interviews with your most active users via Skype - Intercom will tell you who to call! At this point doing gonzo usability tests on feature ideas will also be more valuable than trying to interpret the feedback from your numbers - if you are only getting a few sign ups a day its just not useful to look at the graphs.

5. Make yourself very open to feedback

This is an obvious point, but easy to forget about - I personally don't like products that over communicate with you (getting pointless 'thank you for signing up emails' from the 'CEO' of a startup is annoying in my opinion) but if anyone does want to communicate with you you need to be easily reachable as these data points are gold dust for you. A few obvious things to do:

Twitter / FB - Get your account and page setup before you launch and put clear links on the site. Follow / Friend everyone who uses your app, and creatively re-tweet / share any positive messages, and keep a tweet deck window runnig searching for people mentioning your product in any way. Its also good if you are doing twitter sign up to make it a pre-checked (but removable) option to follow your twitter account.
Blog - Make a Tumblr from day one. Blog posts give you an excuse to reach out to people, and they provide context for feedback - people will comment about you post on twitter for example.
Intercom email - Another intercom plug! Use the Intercom feedback system to manage all inbound email. It keeps everything in one place and it much better for you and your users.
Put your direct contact details on everything. This is so obvious, but a lot of people don't do it - yes, try and get users to use the intercom email / social media channels to reach you, but you should also make it really really easy for them to email your personal email, phone you and drop by your office to see you.

6. Make measuring part of the design activity

So you've done all the above, what next? The really key step to becoming data driven when you have such tiny amounts of data is to make sure you keep trying to be data driven despite it. So, as you decide what to build / promote next make sure that the analytics that you do have is present during design meetings, and that as you develop new features or ideas you are constantly discussing questions like - what do we know already? How will we measure this new thing? What do we think success will look like?

Finally, you need to make sure you involve everyone in these conversations about measuring especially the marketing and community guys. Using and talking about data should not only be for devs and designers - it should just be 'the way thigs are done.'

7. Accept that if you win you will have to roll your own eventually

If you get beyond an MVP, and start to get some traction you'll outgrow services like Mixpanel quickly. As you understand more about what matters to measure running your own reports, producing custom dashboards and doing more sophisticated cohort analysis become more valuable. You'll struggle to do this with off the shelf stuff, but if you have followed point six this should come naturally-ish - if you are looking at your (admittedly patchy) MVP data daily, and using the data in weekly sprint planning and design sessions then when you reach the edge of 3rd party services should be pretty obvious, and this is a very nice problem to have.

8 (bonus!). Accept that if you loose you should stop

Finally, the flipside to the above is, if you do all this, and you are still getting patchy hard to use lumpy data because you aren't getting real traction (repeat users) then you should stop. In my view software has a half life of some sorts - the length of time it takes to decide to kill something, is, unfortunately, often linked to the sunk cost as people cling harder to a vision they've invested more in. This means that the sooner you get data driven, the sooner you'll know if your idea is not going to work, which means you can kill it sooner and get working on the next thing faster.