A sure path to failure, is not going on a 'problem journey' by foot, but trying to arrive at the destination by 'air'. Like any good journey it should challenge your assumptions, and constantly change your view points.

 

At zero customer/user meetings, all you have is a hypothesis. After first five meetings you start asking better questions, After the first 10, you start to see patterns in answers. After 20, you really understand segmentation of the market. After 30, you have a really good understanding of what it is that you actually need to go build. After 40, you really understand what it takes for them to buy, and what change management needs to happen.

 

Time and time again, we see problems which operate in the 'important but not urgent' space, devoid of any quantification, not assigned to an individual, lacking understanding of the problem (the bit) before and after the problem, and lacking understanding of the consequences of not solving the problem.

 

Diving into these into more detail, with examples showing our own 'problem journey' with hiring incubators, before we've written a single line of code.

 

Important but not urgent: There are a hundred and one important things that our customers/users should be doing that they aren't. Very often, people live in the urgent  and important space. 

For example: When we launched the 'innovation incubators' focused on helping individuals and teams, we failed to realise that innovation is an important but not an urgent problem for organisations. Thus the sales cycles have been 1+ year long. After 2 years of successful case-study after successful case-study,  we still failed (in terms of scale) to convince leaders that they should invest in people innovation (first), rather than lead with product/service innnovation.  We have recently decided to take all our lessons of designing a virtual learning incubator model and apply it to both an important and urgent use-case - hiring. We reflected on our first hand experience of the problem, as past hiring managers we made really good and really bad hires. We arrived at our personal view of the problem, that the hiring process (much like a startup's business model is full of assumptions and hypotheses, which are not properly tested) is a key contributor in bad hires.

 

The problem before and after the problem:   Without understanding all the 'interfaces' (the bit before and after) of your customers problem, it's likely you'll end up developing a minimum viable product not a minimum viable solution, the latter being something someone is willing to pay for and has impact.

For example: We're developed hypotheses in parallel for a number of problems before and after the job-spec, it turned out that the problem wasn't with just the job-spec, but our targeted users had problems with recruiters and senior leaders. Uncovering these interfaces, we learned about the pains in developing hiring cases (detailed here), sourcing referrals, selecting, interviewing, onboarding and role development. For each of these we've gone on separate  'problem journey', to build an authentic understanding of the problem.

 

Not a single owner: When there is no owner to the problem, there is no likely to be no buyer. Organisations don't buy, people do. 

For example: We found many hiring managers view HR as rather negatively in terms of their understanding of people so any straetgic partnership was difficult. This led to another hypothesis - hiring managers lacked a structured case to put forward their hires to senior leaders. When we tested this, we realised most hiring managers would struggle to take anything that is not an official process (from HR) to their senior leaders. Notice the contradictions that start popping up. We then realised it had to be a senior leadership driven solution. So, then we started to frame the hiring-case as a senior leadership problem. After interviewing senior leaders we learned about their problems with hiring, they (recently promoted HR and Finance Directors, mid-sized companies, with geographically dispersed offices) were hiring for roles that weren't fully thought out, sometimes hiring at the wrong level, with difficulties in prioritising hiring for the roles with the most value, not able to track ROI of each new hire, difficult to evaluate competing requests for limited resources (budgets), wanted to create a more agile orgnisation that didn't rely on the annual budgeting process acting as a bottleneck for new hires, and make objective decisions that align with strategy (they often only see budget line item requests for new hires). 

 

No quantification:  When there is no quantification, it suggests you haven't really understood the breadth and the depth of the problem. 

For example: We are only now (at the the time of writing this piece) are trying to quantify the hiring case as senior leadership problem. Our recent interviews suggest that senior leaders make the wrong hiring approvals 30% of the time, which translates into hundreds of thousands of pounds of sub-optimal decisions.

 

We have now developed and tested the 'hiring-case' template with a number of senior leaders, and are now in a position to be confident about developing it, because they are willing to pay for it. It is important to sell something frst, then develop it  (this part of another learning blog coming soon). Some of the lean startup thinking involves building prototypes first (versus the design thinking which seeks user input first) may argue that it's too long before prototyping. In our view, we are 'pretotyping'. The bit before prototyping, by going out and testing and testing again our assumptions before attaching ourselves to one or more solutions.

 

For illustration purposes, after having interviewed many individuals with regards to hiring, this is what we are learning: