The Importance of Market Research for Small Businesses

To Boss Your Market, You’ve Got to Know It

The importance of market research for businesses starting out or moving up, including small businesses is down to the fact that the data that research provides, is at the heart of much of what you decide to do with your brand. How you pitch your offering, your messaging, how you articulate your purpose, the methods you use to project certain perceptions, these all depend on knowing our market and the prospects who people it.

Setting off on a brand development adventure to ascertain your positioning without market research is analogous to setting off on travels through the Sahara Desert without a compass. You might try it but you really should not.
You might understand the importance of developing a brand and also for having a brand strategy to steer your business through choppy waters but it is equally important to know that it is complex and in-depth work that should have a basis in facts and numbers and not just supposition and wishful thinking. Empirical evidence is not only good for confidence but it actually gives the power for great decision making.


compass capabilities of market research

What is Market Research?

Market research is a tool, a knowledge base, a marketing, planning and brand development stock in trade that enriches the process of brand definition and sharpens the resulting brand’s effectiveness and the desirability and efficacy of the offerings your business provides. You find and collect information, insights and patterns that expose the potential desires and unmet needs of customers as well as their attitudes and habits. If you remember that businesses like Google and Facebook trade in data about you and me, then you must realise the value of data like that.

Regular market research helps your business grow and continue to grow. It helps your business take stock of shifts and changes in the market place and identify trends and threats in the operating environment. It’s a real risk not to do it because it helps you continue to understand and refine your knowledge about your target market and improve your ability to speak their ‘language’. It means that you can pinpoint problems and possible opportunities and uncover competitors operating in gaps you were not aware of.


What should be the scope and objectives of your market research?

Market Research is famously divided into primary and secondary research types.

Clarity on what it is you want to know about the market at the stage of the business life cycle you are inhabiting determines this, as well as the type and mix of techniques you might employ.

Primary market research focuses on collecting unique data about a business and target customers to use to enhance your offerings and relies on getting as close to the customer or prospective customer feedback or behavioural data from their interactions and transactions with you, like how effective sales is, how effective your sales channels are etc.

Secondary market research is conducted at a remove from the customer and their direct behaviours, feedback and reports, being derived from readily available and compiled from a range of sources.

With primary research, you focus on data and metrics for:

Competitor and industry research
Competitor Services
Communication channels
Focus Groups

You focus on the following with secondary research:

Published company reports data
Industry and sector-specific data
Government data and sector reports
Third-party surveys and studies
News and social media reports, reviews and the general themes shared in forums etc.

Things to Remember

It’s important to ascertain when you start a market research process what data is required, why and by whom, whether similar research has been performed, especially recently and try to mine it or adapt it to your requirements. This may mean that you do not need to carry out your own primary research but if it does, it is instructive to define how and who with. A hypothesis or general idea about the broad nature of the target market is also needed.

10 Reasons You Must Have Market Research

Start your business or relaunch it on a stronger footing

For brand development and to underpin a brand strategy

Compete with established competitors who are confident and slick because they’ve got market research insights you don’t

To scale

To differentiate and diversity

Learn about the customers you want, the customers you’ve got and the potential customers you’re missing – extend your line or offerings

Know and undermine your competitors by identifying opportunities in performance, pricing and promotion

Make informed decisions

Test new offerings and markets

To speak to your prospects in a language they understand and build brand love and loyalty now and forevermore, Amen.


Bridge the Knowledge Gap with Market Research

Businesses that engage in regular market research grow faster and are more successful than competitors who do not. This is why market research is not just for new businesses and is especially precious for small businesses and professional services businesses that face intense competition. When it comes to defining a customer experience that can give you an upper hand in retained USPs, market research is critical for the data needed to design it,

The Software Engineering Mindset

How a Software Engineering Mindset Could Break the Spiral of Failure

Software engineering cultures have created many of the solutions and applications without which our lives as we know it, just wouldn’t be possible, just wouldn’t work. So it’s easy to see that the outcomes and impacts of software engineering can and do change the world. 

From Netflix, Google to Facebook to Microsoft and Apple, we are surrounded by the brilliance that software engineering can engender for the world. They give the lie to prevalent software engineering personality tropes too. Software engineers come in all shapes and sizes but speaking as someone who is natively a software engineer and who manages teams of them, the one trait they all share is overriding respect for striving and for solving.

Yet we hear of IT programme after IT change program that fails deplorably, irredeemably. 


I am very fortunate at this point in my career to be working in an excellent team of leaders who demonstrate just this mindset, with those leading us having a clear-eyed understanding of what compromises must never be attempted while fostering, even insisting on innovation. But I have at times worked in somewhat different environments and since COVID, the number of ex-colleagues in a vast array of other sectors who are reporting a scale of problems that my prior experiences have made me very able to sympathise with and my musings about them have led me to write this article.

Russian Doll

The normal structure of a program is that the engineering team is a team or teams within a larger program management construct that adhere to a discipline with a set of rules and structures within their internal teams while other rules obtain externally. 

The Agile movement aims to bridge that divide and does to an extent ameliorate some of the most important issues – specialist to generalist functionality, working at purely unitary levels, poor communication, delivery focus and iteratively built small linked component –  but it’s simply not enough as we see in the sheer number of rather large and impactful failing projects. 

 Software Engineering Mindset is only for Software Engineers – or is it?

One of the reasons, I think, we see problems often is that there is a perception and it is certainly the practice, that an engineering mindset is only borne by software engineers. In fact, it would make sense if all the people involved in delivering a project were aware of and adopted a software engineering mindset especially when critical decisions need to be made. Now, even when we can get project managers and business analysts and other non-engineers on the team to adopt a software engineering mindset, those responsible for governance – sponsors and executives who naturally focus on constraints like budget and time over arguably value and expediency rather than engineering tenets that will deliver an almost guaranteed result, also require a software engineering mindset when it comes to developing solutions. 

As Chinenye Ikwuemesi lyrically describes (I want to be the software engineer in that article if I am not, don’t you – even if you’re not even a software engineer!) in her article, software engineers seek to solve problems with precision, elegance and style – it’s got to be fit to solve the problem. There are rules for engineering but problems do not respect rules – their very unpredictability is why the rules and discipline of engineering matter so much. We can harness the wind and bend steel and change the direction of a seemingly unstoppable force given enough motivation and resources to engineer a solution. The one casualty of this might be time. But when it comes to real-life projects you can run the risk of being pennywise with time – gain a few seconds on the project to lose days, months and years in business as usual. Save $0.5m  a half here and there only to spend $10m there on gaps the engineering might have plugged. 

There is a constant tension between the engineer’s need to take the time required to actually do the work and solve, and the executives need to shave off time and money where they think it’s possible and justifiable. There is an uneasy tension between what engineers may believe is justifiable and what sponsors believe is. In my role, I feel this tension keenly. The manager that I have to be, understands the pressing constraints while the engineer in me is resigned to the fact that certain things and processes will take as long as it takes, even while casting about for new approaches and considering other possibilities and running these equations in parallel in the back of my mind. 

Equivalents of Real Engineering Compromises in the Real World

It’s a queer thing. Nobody as far as I know, and I do hope this is the case, asks surgeons to close up patients before the operation is complete to save time or to leave implements in the patient to save having to dispose of them or having to wash and sterilise them. 

Nobody asks pilots to do whatever is necessary to reduce the length of a flight if the plane is only capable of doing a certain speed and the rules of time and space will not bend to his ready pilot’s charm, however much money it might save. 

Even on the erstwhile Concord flights, the calculations do not change – the plane’s capability might. So what do they do? They do what is safe and what is sustainable. They work around the fact that reaching a destination requires a sometimes undesirably long, arduous and expensive journey, and accept asymmetries. Getting passengers off halfway through the flight to trudge through the Sahara desert to save on fuel is not an answer to any conceivable question. Yet this is analogous to what is sometimes required of engineering teams. 

A Software Engineering Mindset and Sustainability

Again, what is sustainable? What is the realistic timeframe to find a solution, build it and implement it? In recent years, bridges built in substandard ways to save money have just…. given up and caved in beneath cars and on top of the unwitting people below leading to lost lives; rail tracks built with substandard materials or practices have buckled and created disasters. 

Problem-solving is in its way, precise, as long as you understand the problem. You put this here and that there and pull that down over there and it’s a kite or a plane. 

If you take a Jenga mindset when a software engineering mindset is called for, it all falls down. 

Yet people seem content to make and accept these compromises in the interest of saving time and money. 

The ‘CEO Horizon’ Factor

Look, in some places, a CEO or an executive comes in for a few years – he has to make his mark in about 5 years and is judged on these same efficiencies highlighted above, that give birth to monsters of inefficiency through multipliers in several aspects of the business. But it might never be that CEO’s problem. Another CEO will have to ‘transform’ their way out of it but is likely to fall into the same pitfalls. And the wheel turns, and over and over again, we make unsustainable software, decisions and workplaces.

The Scourge of ‘What might have been’

The true horror lies in the fact that the time and money being saved is a pittance compared to what might have been saved and what might be achieved if the solution is allowed to be fully realised. Somebody has to mind the pennies, sure, and people’s productivity can be improved with goals, leadership and some chivvying but sometimes, we chip away at the wrong things.

Software Engineers tend to have a simple guiding purpose to find the innards of the actual problem – the root cause if you will then worry at it till it reveals the kernel at the heart of the seed that grew that root;  then they need to figure out how to grow a better tree. All engineers have the same drive in whatever field you find them, It’s how we are built. Doing this over and over leads to mastery and given autonomy, good engineers will rebuild this world for the better. In the meantime, they can certainly build the solution your organisation needs given these enablers.

What is a Software Engineering Mindset

The software engineering mindset is purely about the willingness and motivation to solve problems, to be interested in all the pieces of the puzzle, how they fit together and the parts you can’t see or understand yet.

It is about awareness, knowledge and interest in a range of tools and technology to survey the full spectrum of available possibilities to plug gaps, and attempts to find applications that can prise open an enigma when nothing else has worked.

It’s about a mind that can roam outside of the confines of the problem to find an application from another context that may be applicable. It speaks to truly caring for the impact of what you create or fail to,  and dedication.

It’s about daring, it’s about creation, it’s about solving.

A software engineering mindset refers to knowing how your best solution for a component will work, fit and integrate with the rest and understanding that if at any of these levels it fails, it is suboptimal or ensuring you have some options to address those failures. 

A software engineering mindset is obsessed with the overall architecture and takes a global view of problem-solving in the context of the solution. It knows and understands areas directly outside of its own sphere and control, understands the dependencies and risks that arise when you pull a component out of the whole.

A software engineering mindset never loses sight of the problem we are trying to solve as-a-team, and never stops burning to find a real solution. A software engineering mindset is not just for engineers. Finally, a software engineering mindset recognises that we are in the capability business – we deliver power and capability to make the things that were defined as necessary, desirable and high priority, happen. It’s a great example of systems thinking.

This mindset is unlikely to produce a specialist ‘MichaelAngelo’ type of engineer who while they may build a single large product of immense brilliance over a long space of time is unlikely to work on a project team.

Themes of the Software Engineering Mindset

Good cultures if they worship anything, worship excellence in what is created not the creator. The latter creates cults which as we have seen can get toxic very quickly. Good cultures strive for excellence; great cultures get the freedom to attain it and do not hog the credit.

Good cultures know the best engineers and programmers are creative and honest,  they value innovation and do not stifle it with bureaucracy; great cultures foster and mobilise the innovatory muscles with great leadership and vision. Leaders with the power to do so should be focused on getting their engineers everything they need to succeed instead of removing pillars of stability or force them to compromise on big important parts of the solution. Actions and risks should be mapped to the specific part and power of the solution that is affected. This means a non-engineer leader can appreciate the impacts of varying a sprint or backlog schedules and the like.

See the Whole Picture

Ultimately, in a delivery team no matter how large or small or how they are structured, all sub-teams have the same goals, and it’s important to reinforce this through communication, a team ethos and building a culture that is based on adopting a software engineering mindset across the board and implementing processes and structures that support and strengthen this at every level. If the focus remains on identifying with great clarity and then keeping the focus on the exact dimensions of the problem, even while everybody is working on separate parts of it, the chances of success are far greater.


The software engineering mindset keeps everybody focused on the big picture

©G Renee Guzlas

Kennedy Ikwuemesi is the Head of Engineering at Pollinate International

He loves coding and architecture and all the different ways of solving problems in joined-up ways.

You cannot copy content of this page