Anyway, there are lot that I would like to comment, but lets keep it short:

I think you need to clarify the product vision before you go out the building and start customer development. Use the vision as constraint for the customer wishes so that you do not end up developing product that tries to serve everybody and serves nobody.

Use customer development then to validateU/test your vision, be prepare to drop some customers or come up with several products (MVPs even).

If you’d like to have more detailed thoughts or hear more about the war story with similar case just drop me mail at marko dot taipale at huitale dot com.

Regarding us being a startup or not, I agree that the 50 person parent company is not that much of a startup, but the subsidiary (arrivalguides) which only have 8 employees is. Or I should say that it needs to be. Like Steve said: this is very much like changing the engine of a running car, although I usually say changing the engine of a flying plane. The thing is that we have to change the engine in order to make this business really scalable. I want to do this by applying my experience with startups and my new found love Lean Startup.

I completely agree with Satish that rewriting the whole thing at once is probably as far from Lean it can get, and I should approach this with just doing the necessary action at the right time.

I just got my KISSmetrics invite, so that will be one of the first actions I will take, implementing that in the current solution to measure some more stuff.

I’m also working intensly with Google Analytics to try and set up goals in a good way. The problem is that is has been implemented in a way that gives each partner a unique tracker. *sigh* So adding goals will be a bit tough, but I need it anyways.

Laura: I’m not so sure that usability measures are that important in this stage? Isn’t that more important once you have decided on a user story to develop and then test the usability? I know that usability is overlooked by many, often me included, but I’m still not convinced this is the right place for it, please do try and convince me!

And I agree that this isn’t the easiest fit using lean methodologies, but that’s exactly why I want to do it. I won’t know for sure if it works without testing.

Maybe you want to follow the lean startup method concept of interating rapidly through developement cycles to elminate waste to make sure you are doing the right thing.

so you take an idea, like what is the core of our product, what is everyone of our customers doing with that feature, what about that needs to be imporved to make it easier on us and them? that is you hypothesis.

then you make something to do something and figure out how you’ll measure it to see if it meets your hypothesis. in the discovery phase, this could just be a process of reviewing all the custoemrs who’ve signed up to use your product and reviewing the work that went into each setup for them, trying to collect data on what was the most common often repeated process that you did for them. you collect that info and run metrics to see which feature wins.

then you think about it, analyze and learn.

then repeat. now that you know this one thing, what new ideas do you have? how can you build something to test that idea, what do you need to measure to see if your idea was correct? do it and learn. then repeat for something else. maybe you’ll find something that you can improve to speed up the new partner integration process. build upon that success with more success.

i don’t know, I’m not the expert. I’m going to get drunk now because I feel stupid.

this is interesting, but I do not think it fits the lean startup model. I don’t think you are a startup at all. you have 50 employees, a bunch of paying customers, and a business model that is bringing in money. it sounds like you are looking for ways to easily scale what you have, because it sounds like it is too costly and involved to sign up a new customer.

so whose problems are you solving, your problems and frustrations, or your customers?

you are not building 1 product for x number of customers. you are custom building unique products for each customer. as long as you have salespeople that sell that way, you will not be able to use a lean startup method. and as long as you have 50 employees you need to pay each week, your CEO will have a hard time agreeing to a change in the way your salespeople sell. once the money starts, it can’t stop.

maybe your product that you build will not really be a product, but instead will be a process for customizing your application for each paying partner that comes along. the faster you can do this customization, the more paying partners you can signup and increase sales.

maybe it’s like ordering from a menu at a restaurant. your meal can be cooked to your liking and you can have a range of dishes that you like, but your choices are limited by the menu.

so what have you learned so far? i’ll be watching this to see what is new.

Once you have these metrics identified, identify your top metric and make changes in your application to track that for this iteration. Every iteration you verify if your key metrics are being tracked if not, identify the top missing one and add them to your code base.
Similarly for your codebase changes, identify your key pain points, the things that are hurting you and re-factor only the current top pain point for each iteration.

One of the key things of the lean process is to do just enough and not more then required at every step. Learn and then redo. Do small, incremental changes at every iteration. Each iterations are small but you do many and fast iterations. Due to the compounding effect the changes will be huge within a small amount of time.

So your first goals should be
- Have an continuous deployment system
- Identify key metrics and capture those
- Small and fast iteration cycles in your work process.

With regard to your actions in the analysis step, I would strongly recommend that you not leave out some qualitative research: interviews with end users, observations of people using the software, usability tests, etc.

You may have “many customers” but most of your customers are not the end users. Gathering qualitative information from those end users is an outstanding way of learning important things like why people aren’t downloading, or what people are doing with the guides, or whether they are returning over and over again. These are things that are generally impossible to determine from pure metrics, but they’re incredibly helpful in figuring out what the actual minimum feature set is for a MVP.

I know it seems like it’s just adding time, but really, interviewing a few customers and potential customers and watching end users with your product can generate great hypotheses about what to include much faster than anything else I’ve seen.

Good luck!

But we take time. We use a technology nobody else does. We do only what customers ask but don’t do EVERYTHING our customers ask for. And when designing a feature, I always think like “how this will be used in 10 years?”.

And that thing with sales people – exactly. I don’t want a team of SAP or Microsoft like salesmen. It is exactly the kind of business i DON’T want. So instead we take a time and we are slowly finding ways how to do this better…

Maybe this comment is confusing, but let’s discuss.

You almost had me when describing your company as a start-up. You sure have several of the issues of a more senior corporation. Or it at least sure sounds you have a maintenance of a legacy application at your hands.

I feel you have two basic strategies to choose from: 1. restarting the development from scratch or 2. wrapping existing blobs of stable & tested functionality behind interfaces and concentrating on new functionality. And maybe, if the solution is still small enough, there might be an option 3. A small task force could refractor the existing solution to something that could be maintained more easily.

It seems you have already selected re-building everything – MVPs and all. In my mind this works, if you have all the expertise from previous products available. It’s quite easy to build the application, if the key members of the dev team have build an application in same problem domain several times before.

These key members of your development team should also be able to tell if there is anything valuable (and stable) enough to use as a black-box component from the current solution.

I just hope you have the core team in place & you don’t have to face the politicking associated in such renewals in larger corporations!

Cheers, Sami

This post was mentioned on Twitter by andefred: Using Lean Startup Methods Revamping a Complex Product – Part 1 http://bit.ly/adVVZN #leanstartup feedback greatly appreciated…