Effektif - 6 August 2014

A slightly unusual setup - the founder Tom is in Belgium building a product for large customers like those served by the lone investor, while Peter is here in the UK working to determine whether there is a market in smaller firms for a lighter product. The underlying product provides simple workflow automation, similar to IFTTT but for harried business folks who have a complex process to follow - get email from system A, create spreadsheet, get Phil in Accounts to add three columns, send to system B, export to CSV, ....

Peter wanted some coaching on Customer Development, which I was happy to provide. I suggested starting with a profile of his imagined customer - a worker at a midsize company who is drowning in incoming work and undocumented, complex processes that are needlessly manual. Next, he'll want to identify industries that particularly have this problem, for example law firms or local government bodies. If he's done the profiling right, the next step shouldn't be too hard - using people he knows, LinkedIn, and any other source he can find, start contacting people who look like they match this profile, either by email or (even better) phone, and set up in-person meetings with those who respond positively to qualifying questions about the profile (chiefly, "are you overwhelmed with manual processes in your job?").

Peter was a bit worried about getting meetings at this stage - it often surprises entrepreneurs that potential customers will meet with them so easily. But the thing is, people love to complain, and if they are feeling the pain enough, they will happily take you to lunch to tell you how bad it is, especially if they think there is a small chance you can solve it for them. If he doesn't get this type of reaction from at least some of his contactees, he probably has the profile or the industry wrong.

At the meeting, it's important to be very open to what the user tells you - what she sees as her problem may not at all match the product you built (it's a miracle if it does, actually). A simple example - users may say that their chief source of work is the phone, not emails, and incorporating this might be a significant product enhancement. If this happens, Peter shouldn't give up, but should go on building a profile of what users actually need - if he finds a common theme, then he has a case to make for Tom and others to enhance the product to capture those users. This very open attitude may mean you don't ever demo the product to them - that's OK, because this is customer development, not sales, and your mission is to understand what they need. (Of course, if a paper or real demo helps achieve the listening goal, by all means go ahead.)

Finally, Peter will want to get a clear sense of budget from these meetings. If users feel pain but are only willing to pay five pounds per month to ease it, then there is no meaningful market for Peter's imagined product. An interesting thing to find out is what the users can pay without anyone else's approval - this was a very useful pricing strategy at my previous employer TIM Group, for example. Peter is unlikely to find out about preferred pricing structures at this stage; users won't know whether they want to pay per month, per transaction, or something else, but they should have a sense what they could pay overall, which is enough for Peter to use in building his business case.