How do you shift from solution->problem to problem->solution?

Corporate innovation efforts are often confused with research and development efforts. They focus on defining a solution, and only then begin looking for problems that it can solve. They to a large respect a victim of their own success. Their stable business affords a large R&D budget, which then outputs new technology in search of a market. It is only natural that innovation efforts then focus on exploring new markets for existing technology. The unfortunate result of this trajectory is a mindset focused on building solutions, rather than understanding problems. 

Startups have a completely different set of challenges. Most early stage startups lack the resources to build proper solutions. Instead, they focus their limited resources on understanding problems. They then use tricks such as spoof landing pages and vaporware to validate demand. Only once a need is well established do they raise sufficient funds to build a workable solution. It is no surprise then that they solutions startups build are often more suitable that those built by corporates. They are built AFTER the problem is understand, not before. 

The startups that have too much money too early tend to build solutions that are ill-fitted to the market. Just look at Quibi, which managed to burn $1.5 billion in investor money before getting a product to market. It was no surprise that nobody ended up actually wanting to pay for their product. 

Corporates should certainly not abandon their R&D efforts. They are essential for sustaining the existing business, and they provide a competitive advantage in building solutions when real problems are defined. However, they must get out of the way of innovation. Lean efforts that focus on understanding customer problems are often more successful in discovering the next generation of growth opportunities.  

User pain points and customer objectives should be systematically mapped to determine priorities for solution discovery.

A detailed mapping of pain points stakeholders, activities, and processes reveals blind spots in management awareness. Establishing the decision-making authority at the beginning of a project can help reduce bottlenecks and internal uncertainty among team members. More specifically, it outlines the functional roles and responsibilities of each stakeholder across major tasks within a new project.

A RACI model specifies the key roles and responsibilities of the team members in charge of any major task. More specifically, RACI stands for:

Responsible: The person with the decision-making power.

Accountable: This person is accountable for the task being correct and complete.

Consulted: The consulted party is a small group of people who are experts in a relevant task to the project.

Informed: These people should be kept in the loop regarding the project’s progress and make communication fundamental.

Pain Point & Objective Prioritization

Impact: What will be the benefit of deploying a solution? Viability: What is the probability that the benefit will be achieved?

Viability: What is the probability that the benefit will be achieved?

 

Tracking roles and activities can provide a quantitative basis for setting and measuring improvement objectives and identifying digitalization initiatives

 

 

Improvement objectives are clearly defined in collaboration with the Client and are associated with both system users and performance metrics.

 

IoT ONE Insights

Download PDF.

* Required
* Required
* Required
* Invalid email address

Thank you for downloading PDF!
PDF report was sent successfully to your inbox.

Related Insights.

Contact us

Let's talk!

* Required
* Required
* Invalid email address
Yes, i want to receive the IoT ONE Insights - Newsletter.
Go to Action

Thank you for your message!
We will contact you soon.