In this post, we explore and share the top four telltale signs ⚠ that indicate a company is project-led.
Product-led and project-led strategies are different approaches that can be combined or emphasised to varying degrees depending on the business context and goals. Many investors favour companies that follow a product-led growth (PLG) strategy. They anticipate that these firms can achieve significant annual growth rates, typically a factor of 2-3, depending on the stage of development. This is a feat that can be challenging for project-led businesses, where revenue is directly correlated with headcount. While it is evident that IT consultancies, for example, operate in a project-led manner, there are instances where other tech organisations claim to be product-led. Yet, underneath the surface and often unaware, they are still undertaking software projects – which frequently represent the lion's share of their revenue. Those companies encounter challenges such as high maintenance efforts, slow feature delivery and inability to roll out updates efficiently. In our technical due diligence assessments, we look for telltale signs that indicate a company is project-led in reality. This allows us to provide our clients with a better understanding of the implications on scalability, explain the associated risks, and offer recommendations to mitigate those risks.
In general, there is nothing inherently problematic about companies embarking on software projects. There is a considerable roster of large and medium-sized IT consultancies, such as Accenture, Capgemini, and IBM Global Business Services, which employ vast numbers of staff and generate substantial revenues. Their sole business is executing projects; they are transparent about this and are well-equipped to manage them.
Extensive project work can present challenges if a company sells a product that necessitates substantial adjustments before a new customer can utilise it, such as the availability of adequate project teams and efficient processes. This is often the case for B2B products aimed at medium and large enterprises, such as ERP, CRM, or manufacturing solutions. Successful vendors in these industries establish a clear distinction between the product and the associated projects through distinct departments, separate organisations, or by utilising a partner network. This involves having a well-defined concept for customisations, segregating product development from project teams, and establishing a partner network to scale the product rollout.
In our technology due diligence, we frequently encounter companies that have not adequately addressed the aforementioned issues - product versus project - despite their claims at the beginning of the assessment. This might be a startup, for example, still searching for product-market fit, where the future delineation between product and project remains unclear. Or, it could be an established player that has been producing hundreds of customised versions of its software over the past 30 years without a clear strategy and has now reached its technical limitations. The outcome, in any case, is that the business will or has evolved in an opportunistic and decentralised way, frequently lacking a strategic central perspective and vision. IIt’s often purely tactical, very commercial, and unintentional— not necessarily bad, but not scalable and potentially risky.
For these types of companies, this article provides an overview of potential issues within the product and technology departments and the associated risks for the organisation.
Potential issues in a project-led organisation and resulting risks 👉 Sign #1 - Lack of Product Management A well-functioning and adequately staffed Product Management function is crucial for driving product development. The lack of such function is a hallmark of an organization that is not product-led.
What to look for?
Product Management Not Part of the Leadership Team: The company does not have a Chief Product Officer (CPO) or a similar role to represent product management within the leadership team.Lacking Product Management Resources: The product management team is understaffed. Our recommendation is to have one Product Manager for every 4-5 engineers.No Product Roadmap: The company lacks a convincing and regularly updated product roadmap.Feature Backlog Not Well Maintained: The product backlog is either insufficiently populated or infrequently maintained, with features lacking user stories (business value), detailed descriptions, and acceptance criteria.Why does it matter?
Opportunistic, sales-driven decisions are hindering strategic product development, causing the company to miss business opportunities such as up-selling, cross-selling, or internationalisation, thereby ultimately diminishing product-market fit over the long term.
👉 Sign #2 - Resource-intensive customer onboarding Reducing the resources and skills needed to onboard new customers is essential for selling a product at scale. Resource-intensive onboarding is a characteristic of project-led businesses.
What to look for?
On-Premises Installations: The product is installed in clients' data centres, where heterogeneous IT environments complicate installation and updates, making the maintenance process extensive and resource-intensive.No Standardised Onboarding Documentation: Self-service onboarding of new customers is not feasible due to insufficient product documentation and a lack of video tutorials.Staff Not Available: Key contributors are unavailable for knowledge sharing within the company (or for the Tech Due Diligence🙂) as they are needed on-site to address critical issues with customers.Why does it matter?
The scalability of the company is limited, as new staff must be continuously hired and trained as the customer base expands. The lengthy onboarding process results in revenue loss, as customers typically do not pay licensing fees during this period. Ultimately, this can damage the company's reputation, as complex projects are often underestimated in both time and costs. Maintainability is likely to be a nightmare as well.
👉 Sign #3 - Immature agile process Developing products using an agile methodology is considered best practice and is recommended for most engineering teams. However, many large customers still prefer to roll out projects using a traditional waterfall process - our next telltale sign.
What to look for?
Frequently Changing Sprint Goals: Sprint goals are adjusted mid-iteration due to incoming "urgent" customer requests.No Regular Updates/Releases: Product updates are not released on a regular schedule, as the primary focus is on customer-centric deliverables.Frequent Reassignment: Development teams lack stability, with resources being moved in and out of project teams as required.Why does it matter?
Engineering teams are working with low productivity due to frequent project changes and constant context-switching. This leads to increased frustration and potential resignations. The continual pressure to deliver client projects results in the neglect of quality assurance practices, such as writing automated tests, leading to higher than necessary levels of technical debt (check out our post on tech debt ).
👉 Sign #4 - Customer-specific artefacts (aka documents) Large volumes of customer-specific artefacts, such as documentation, contracts, or code, are clear indicators of a boutique-style and therefore heavily project-led business model.
What to look for?
Customer-Specific Documentation: Significant volumes of project-specific documentation exist, such as a dedicated Confluence space for each customer.Customer-Specific Source Code Repositories: The source code of the "product" serves as a template for projects, and is copied and customised for each customer.Customer-Specific Deployments: A dedicated deployment is created for each customer (whether in the cloud or on-premises) due to their specific requirements, such as IT security policies, compliance mandates, or the need to "pin" a certain software release.No Standardised SLA Reporting: Standard Service Level Agreements (SLAs) do not exist; instead, they are negotiated individually with each client.Why does it matter?
Customer-specific artefacts lead to escalating maintenance efforts with each new customer. As vendors struggle to scale resources in advance, product updates are not rolled out regularly. This results in a growing number of bugs and unpatched vulnerabilities, thereby increasing the risk of data loss and security breaches.
So you ended up with a project-led business rather than a product-led one - there are ways forward, it won’t be easy, but you can get help Once the issues have been identified, a strategy for transitioning to a more product-focused company needs to be established. However, whilst possible, migrating from a project-led business to a product-led organisation is typically a complex transformation challenge and can take several years.
The transformation process generally begins with the challenge of establishing a new culture and hiring several key personnel. While project teams concentrate on delivering their projects on time and within budget, product teams should strive to create product value.
This will also necessitate changes in the organisational structure, such as separating project work from product teams. While the most obvious approach to achieve this is by creating separate departments, various successful market players have opted for an even clearer distinction by establishing a dedicated entity for projects and consulting.
Alternatively, building a network of implementation partners could be a viable long-term option, although it requires careful planning to ensure success.
After the initial organisational changes are in place, the "real" work begins. This includes establishing product management best practices, implementing agile development processes, and designing a new software architecture.
And even when the product and processes are adjusted, the transition is not complete: existing customers need to be convinced to migrate to the new solution one by one, contracts have to be re-negotiated, and time-consuming data migrations might be necessary.
To confirm the existing business character, product-led or project-led, and to map the potential and cost of a shift, we recommend a comprehensive Technology Due Diligence with TechMiners. Our expertise will help verify core attributes and provide insights to facilitate a strategic transformation successfully, if required.
