_Originally published by Bhragan P. on Last Week in ConTech on September 5th, 2024_

[View original publication](https://contechroundup.substack.com/p/why-do-so-many-solutions-fail)

---

Each year 100s of new AEC solutions go to market representing hard work, sweat and endless stress from the founding team.

Despite this grit, so many fail to gain traction or raise funding. It’s disappointing for founders and the industry alike, and through my years in the industry I have witnessed startups make the same mistakes time and time again.

After spending time coaching a few teams through the common traps, I decided to consolidate these learnings into a framework to follow, a ‘Maslow’s Hierarchy of Needs’ if you will, for selling to GCs.

This is not a full guide, but should provide a starting point and help sharpen go-to-market approaches for new contech teams. And hopefully, as we used to say, help you to avoid being ‘graveyarded’ - becoming a solution which never makes it past a pilot.

-------------------------------

Contents

- Why do so many solutions fail?
- Industry Integration
- Solution Alignment
- Project Fit and Adoption
- Reading Time: 9 mins

--------------------------------
### Why do so many solutions fail?

The number one question I am asked is why so many solutions seem to fail in construction. 

Each case I have seen is nuanced and varied, however they fall broadly into one of the following three categories:

- **Industry Integration**\
This where a solution fails due to a lack of industry knowledge or failing to understand the unique organizational structures.
- **Solution Alignment**\
This is where a solution fails due to shortcomings with the product itself or not understanding the broader value drivers for the target construction team.
- **Project Fit and Adoption**\
This is where a solution fails as it doesn't fit the specific needs of the pilot project chosen or the people present on site.

![Why Solutions Fail](https://res.cloudinary.com/dfitptng8/image/upload/v1725650355/why_solutions_fail_2a0d247ddd.webp)

As seen in the graphic, the categories build upon each other and a founding team ideally needs to meet the lower tiers before attaining project fit and adoption within an organization.

Understanding the framework helps founders to diagnose and address potential risks at each stage of the solution’s lifecycle and mitigate them. Let’s dive into each category and the common failure modes within them.

### Industry Integration

Construction is commonly referred to as an ‘industry of industries.’ This is because construction has multiple distinct sectors which are varied and unique to each other. For example, building an apartment building is quite different from building a bridge, with different construction methodologies, designs and regulatory needs such as zoning requirements or labor laws.

Due to this, each sector has specialized processes and most contractors and designers tend to specialize in one or two of the sectors.

What is common across the sectors is the general ‘process of construction’ and the project stakeholders. These nuances between the industry sectors can be complex and unfamiliar to those external to the industry which brings us to our first common failure:

**(1) No Construction Experience**

When we review solutions to use on site, a red flag often is if the team has no construction experience or background.

To build an MVP which addresses a real pain point, industry expertise is a must. It can be overcome through customer discovery or advisors, however the majority of solutions which don’t have this understanding, end up missing the critical perspective which addresses a real problem.

A common trap is attempting to reengineer an existing workflow as it appears, from the outside, inefficient. While this may be true, no one on site is willing to try a new method of working unless:

1. There is immediate and obvious value.
2. They trust you and your solution.
3. The integrity of the workflow is maintained.

Without having industry expertise, it is unlikely that your MVP will meet a critical pain point immediately, and if you don’t speak the language of the project team or have a proven track record, they won’t trust you. On site the most common question is, _‘How do you know what you are talking about?’_

To overcome, embed a construction industry advisor, mentor or early hire in your team.

**(2) Understand the organizational and enterprise requirements**

Every construction company has unique processes and requirements (or ‘hoops’) which startups have to ‘jump’ through. They can appear archaic or unnecessary, but proving that you are prepared to work with the organization to meet their requirements is necessary.

The reason is that as an industry, we are heavily regulated due to the inherent risk associated with building. Construction failure can result in the loss of lives.

Even if your solution alleviates a critical pain point, if you don’t show a willingness to listen to feedback and develop new features, contractors will disengage and are likely to turn down a future pilot.

An example is IT often has specific security factors which must be met before a solution can be adopted.

As the startup team, you can show your flexibility by having a willingness to listen, show effort on your side by including it in your roadmap or placing it as a strategic priority.

**(3) Approvers and Users are different**

One solution I worked with had incredibly successful pilots and feedback. However, they found that their solution wasn’t being adopted or used at scale.

The reason is that the approver, the person making the purchasing decision, was different to the piloting team and had limited awareness of the success and utility of the solution.

As a startup, it is important to recognize that the person paying can be different than the person using the solution, and the onus may be on you to communicate between these parties.

I advise startups to identify this approver role early, and to make a concerted effort to collect as much data as possible from early pilots.  Assuming a positive experience, startups can then provide a concise report of the pilot results to the project team, and ultimately to the approver.  This ensures the approver is looped into the process, and that they have all the convincing data ready at their fingertips to support a purchase after a successful pilot.

### Solution Alignment

Once a team has embedded construction expertise and understands the broader industry context, the next focus is the solution itself. The founding team must ensure that the product aligns with the needs and workflows of the construction team. The solution has to work and be adopted on site leading to my next learning:

**(1) K.I.S.S.: Keep It Simple, Stupid**

Some solutions are very effective but from the outside don’t look fancy or seem like ‘boring’ tech.

They gain strong adoption, however, as they significantly improve the life of the user.

A simple and relatable example is when Bluebeam Revu added a feature which allowed users to apply the same markup to all pages at the click of a button. When you need to copy and paste the same call out on a 200 page drawing set, it saves hours and makes people enthusiastic adopters.

As a startup, constantly ask the question to the project team, does my solution significantly improve their day to day?

In the early stage your solution needs that ‘golden button’ or killer feature which significantly improves their lives. It doesn’t have to be flashy. It just needs to work.

**(2) Solution is too difficult to use**

On the same trend, I often find that startups have a killer feature but it is simply too hard to use or access. It might have just one too many clicks or taps to get to the true value of the solution.

This is quite the dilemma for an innovation team, because while a solution may be fantastic at solving a problem, it will not drive any value if the project team just isn’t willing to learn how to use it, or give up because using the solution is too difficult.

In construction, solutions have to be fast, easy and reliable. First impressions matter and no one will talk about your solution if it is just ‘ok.’ Conducting site walks where your support team observes the project team using the solution can help optimize user experience and ensure integration into daily workflows.

**(3) Measure Your Promoters**

Net Promoter Score is a tool used to measure a customer’s loyalty by understanding their likelihood of recommending a given business, with the general question format, _‘on a scale of 1 - 10 how likely are you to tell someone else about this product or solution.’_

While there is some debate around the NPS metric, it generally is a solid indicator of pilot growth potential. In my experience, solutions needed to have an NPS of around 80 (lots and lots of promoters saying great things!) or more to gain adoption on site and be rolled out organically throughout the organization. Keep this in mind when reading the innovation champion part in the next section.

**(4) Don’t forget about support**

The sale of your solution doesn’t end at the confirmation of the pilot. It is inevitable that something goes wrong during the process of rollout to the project team.

How you handle issues which arise and how you support the project team in understanding and learning your solution is critical for success.

The reason is you might have an error, but if the project team thinks you provide fantastic support and are willing to call you up to overcome it, you have developed a level of trust and reputation which will scale throughout the organization.

Unfortunately, oftentimes a team tries a solution, runs into an issue and can’t get a hold of the support. They end up throwing out the solution and never trying it again. Reputation matters.

### Project Fit and Adoption

After aligning the solution to the needs of the target users, success ultimately depends on pilots. For startups it’s critical that they are selling to the right customer and the right projects which leads to our next failure:

**(1) Identify your target project early**

When you are selling your solution, you should know what your target project is. For example, you may know that your solution works great on warehouse or data center construction projects. Developing this specificity early can help build a proven track record in a segment, making it easier to sell to future customers.

I have observed solution mismatch, where the solution is applied on multiple different projects such as an indoor fit out as well as an infrastructure project.  The feedback on the solution is then likely to come back with mixed results, and dilute any positive momentum achieved on good project fits.

While a general approach can work if the solution is broad enough, focusing on a best-fit project segment and scaling within it can help optimize growth for products and services that have targeted value drivers. This also has potential to maximize powerful word of mouth referrals within a segment, and cement a foothold in the industry.

### (2) Find your innovation champions

Sometimes you will sell your solution to a project and then realize that no one is actually interested in trying out your solution.

Once you have sold to your target project, find an innovation champion (or two!).  These are the people on the project team who are highly engaged in your solution and are your ‘hype’ person.

They are valuable as they will push your solution along the project and distribute it as appropriate.

If you don’t have one, you may have to be on site more with extra hand holding, or find that no one is using the tool and/or responsive to your feedback requests.

Find someone who is really excited to use the solution and can be a catalyst.

**(3) How do you get on more job sites?**

Once you are on a pilot, recognize that your solution could be providing value across the entire project team. If you have sold initially to the GC, the other stakeholders such as the consultant, architect and asset owner may have other projects that your solution might be well suited for.

Understand their pain points, how they could find value from your solution and how it could be rolled out through their project portfolios.

This helps increase the virality coefficient (the number of new users an existing user generates) of your solution.

------------------------

Selling to the construction industry requires a holistic approach for adoption. It spans from deep industry integration and understanding to thoughtful solution design and support and, finally, to strategic project level adoption.

Each tier of the framework plays a role in determining if a solution will thrive or fail. By addressing these with care and precision, startups can increase their chances of not just success, but becoming indispensable to the project teams they serve, ultimately helping them avoid becoming 'graveyarded.'
    

Building a framework for ConTech solution adoption

Why do so many solutions fail?

high-angle-view-buildings-against-sky-sunset.webp

_Originally published by Bhragan P. on Last Week in ConTech on May 2nd, 2024_

[View original publication](https://contechroundup.substack.com/p/top-tips-and-pitfalls-to-avoid-when?utm_source=post-email-title&publication_id=1791925&post_id=144230369&utm_campaign=email-post-title&isFreemail=true&r=2t7fju&triedRedirect=true&utm_medium=email)

---

What does a digitally enabled contractor truly look like?

Does it involve the full adoption of BIM? Is it a company which seamlessly pilots and adopts new solutions? Or is it a contractor who has imbued a culture of innovation in its people - a world where everyone continues to explore better ways of working and are supported in doing so?

The answer shifts for every company and is defined by the sector they operate in, the nature of their projects, their business and strategic goals.

One thing is key though, contractors need an innovation or ConTech team to realize this future.

Here’s what I’ve learned on how to build, grow and develop sophisticated innovation teams to enhance the adoption of technology and transform your organization.

---

### Contents

1. Why do we need an innovation team?
2. Who should be on the team?
3. Top Tips and Pitfalls to avoid when building ConTech teams
4. Measuring Success
5. Takeaways for startups

_Reading Time: 8 min_

---

### Why do we need an innovation team?

Innovation is often discussed but seldom acted upon. It exists within all companies as people naturally seek to improve the way they complete their work to save time and allow them to focus on what’s important.

Having a team is valuable as it provides a pathway and mechanism to connect the innovative tendencies of your workforce to your strategic business priorities. They can monitor, seed and support innovative practices within your business and ensure there is no duplicative effort by connecting siloed business units. Additionally they will collaborate with the c-suite to understand business goals and foster directed innovation to help maintain and grow market position.

This team has four key pillars:

- **Awareness & Education**\
The team supports communication and education on innovation    to the organization. This helps improve the visibility of innovative    projects to reduce duplication and enhance organization scaling of solutions.
- **Management**\
The team supports the operational management and testing of new solutions. They work with teams to identify problem statements, discover possible solutions and manage the implementation and coordination of pilots including defining success metrics.
- **Strategy**\
The team supports the businesses strategic goals by prioritizing projects and coordinating on resource allocation. This is as the team's priorities are defined through a strategic goal setting process with the C-suite.
- **People enablement**
The team provides support to the organization and offers a pathway for ideas on improvement to be shared. This allows the naturally curious and innovative people to be supported in deploying their ideas. Without this support they can become disengaged and leave to competitors.

### Who should be on the team?

The team needs a wide variety of skills and experiences. Determining which skills to prioritize is dependent on the size and budget of the team.

If your organization can afford only one person to be focused on innovation, this person doesn’t actually need to be a ‘techy’ person. Tech can be learned.

The key skills required in a team of one is:
- The person needs to be passionate and driven in finding a better way.
- The person needs to be a strong communicator and adept at cross functional relationship building.
- The person needs to have the personality to support and spur culture change. Innovation can be a lonely endeavor fraught with pushback and setbacks.

If you have the budget and support for a team, this means one person doesn’t have to have all the skills. Here are the key skill sets to cover on the team:

* **An IT person**
    * IT support is required for software approval including assistance on security, software compatibility and setting up sandbox environments.
    * Having dedicated IT support allows pilots to be expedited and technical issues to be quickly resolved.
* **A Culture Change person**
    * This person is focused on driving engagement amongst the team’s stakeholders.
    * They are on the ground talking to people and bringing them together to find better processes and workflows.
    * They need to be passionate, have great communication and collaboration skills and have high emotional intelligence.
* **A Field person**
    * This person is an important link between the technology experience of the team and the pain points of the users.
    * They should have project experience, understand how things are built and have experienced the challenges the end users will face.
    * Most importantly they should be able to speak the language of the field.
    * People in the field don’t always trust the office. They want to know they are heard, understood and know someone who is ‘one of them.’
* **A Data person** (nice to have)
    * This person will help with exporting pilot data into reports and integrating new software into existing reporting platforms to streamline workflows and improve real time visibility.

### Top Tips and Pitfalls to avoid when building ConTech teams

1. **Have somebody from the field with building / project experience**\
This team member is a key internal stakeholder to convince before sharing pilots with the field.
2. **A key team KPI should be the number of walks of a job site.**\
It is important to set a goal and have the team on site. This allows them to hear first hand experience from the project team on their workflows, what is working (or not) and to develop relationships which support the team’s goals.
3. **Be outstanding collaborators.**\
There are a lot of people who need to work together for successful adoption including:
    * The customer success team from the startup
    * The project team running a pilot
    * The IT team providing operational and technical support/
 
    The team's ability to form relationships with all of these stakeholders to identify and resolve issues quickly is critical to success and building trust in their role.

---


>_Tech adoption is not set and forget. It takes a team of people working together to train, support and push the roll out of a product._

---

### Pitfalls

1. **Don’t be just from the field.**\
Team diversity is important. It brings new ideas and networks of internal relationships.
2. **No processes.**\
Have clearly defined processes that are continuously updated with lessons learned. An example is there should be a clear pilot process documentation which can be shared with stakeholders such as legal and IT so they understand their involvement and expectations.
3. **Don’t throw tech out for its own sake.**\
Often a higher up will see a new exciting tool or trend and force a pilot. Don’t do that. Trust the team and process to be intentional in finding what is needed and will be adopted.

### Measuring Success

Innovation teams in construction companies can struggle to gain internal support as their contribution to the bottom line and ROI is not always clear.

As a team it is important to build case studies and data points which provide the contribution of your team to the business's strategic goals. Some ways this can be done are:

* **Provide hard metrics**
    * At the start of the year create a list of business goals and processes which can be compared against at the end of the year.
    * For example if a goal was reducing safety incidents on site, track and show the number of improvements including the initiatives the team supported.
* **Track the adoption rate of technology**
    * Use metrics such as number of users or number of logins to understand adoption saturation.
    * This will help to identify hot spots, prove success and identify innovation champions whom you can highlight as successful case studies.
* **[Long Term] Track the change in business priorities**
    * Over a 3-5 year period the businesses strategic goals should have shifted and changed as innovation practices help to achieve them.
    * For example if in Year 1 a key goal was safety and in Year 3 this is no longer a key goal, safety has improved and it could be attributed to the success of your team.

Overall, building a construction tech / innovation team is critical to the long term success of your organization. Being able to understand its value, how to build the team and to track and sell its success to the C-suite is integral in advancing the digital transformation of the industry.

### Takeaways for startups

* There is strong alignment between how the innovation team at a construction company is structured and the composition of the accounts / support team.
* The key takeaways which the customer support team of your startup should follow are:
    * **Have a clear piloting process**\
    For every new project there should be a clear piloting process where your team engages with the key company stakeholders (legal, IT, project team, innovation team) to understand what they need and how you can help. Have an internal document on who manages each key relationship and where you track and share your learnings on the company's priorities.
    * **Have Field experience**\
    A member of your team should be from the field. They need to be able to speak the language of the field so that the project team knows that they are heard and the solution was built for them and the startup team has experienced and resolved the challenges they will face.
    * **Track Site Walks**
    Have your team (ideally someone with Field experience) on site walking with the project team. This will help you to proactively resolve queries and ensure a successful pilot.
    * **Provide seamless reporting**\
    For every pilot the innovation team must report on the success of the pilot, alignment to strategic objectives and potential for enterprise scaling. Make this process as easy as possible for the team by providing easy reporting and customizing to their internal system requirements. This will help you understand what their priorities are and ensure your team focuses on these.









Top Tips and Pitfalls to Avoid When Building ConTech Teams

city-buildings-against-clear-sky-sunset.webp

Stay up to date with the latest from Erin by subscribing below

Blog Coming Soon!

Explore Erin Khan's journey and insights in empowering individuals, advancing technology, and fostering project success in the AEC industry through her EKC Blog.

Blog

Why do so many solutions fail?

Top Tips and Pitfalls to Avoid When Building ConTech Teams

Navigation

Contact