All Resources

Project to Product: a tech start-up evolution

Dan Fletcher
Dan Fletcher Senior Product Manager




culture , development , product-led , start-up

Today, the whole of Dayshape engineering and product management are laser-focused on continuously improving our software for our current and future customers. But it took a while to get here.

Like a lot of tech startups, Dayshape started life working on discrete projects, dealing with customer requests on a bespoke basis as and when opportunities came our way. But as time went on and Dayshape began to grow, it became clear that this approach wasn’t scalable or sustainable. We needed to adapt to better serve our customers and continue to build a thriving company culture.

Transitioning from project to product-led development hasn’t been a walk in the park, but we’re far better off in terms of what we can achieve, and what we can deliver. We’ve learned a lot about ourselves, our customers, and our technology, and we’d like to share how we got here with you. 

Dayshape in the early days

Like many tech startups, Dayshape started out as a consultancy, providing tailored advice and services to large professional services firms, and building solutions to solve customer problems as we found them. We realised early on that planning was a huge headache for our customers and their peer companies. They were struggling to strike the right balance between profitability, client service, and staff happiness. 

So, we started developing technology solutions to streamline resourcing activities and help our customers get the most out of their people. We built the first version of our product before we even had a website. Our first client was super engaged and hands-on, and in those early days, the collaboration worked.

So far, so good. Then came more customers.

We continued on with our process, with some changes to accommodate for our growth. But we soon realised this was inefficient. Duplicating work across planning, delivery, testing and project management didn’t make sense, and having multiple projects with multiple codebases and different features was far from ideal. But the reality at the time was we relied on these customers, and we were determined to serve them as best we could. The consultancy model was still fueling our growth. So, we sucked up the challenges and cracked on.

The change process

Our initial project-led approach was incredibly beneficial to the early development of Dayshape. We had on-demand access to our target market, professional services firms, which pretty much guaranteed us finding our Product-Market fit. We also had access to the facilities that large professional services firms have, such as a professional quality assurance team. And we were being paid to develop our product!

But there comes a point where you start to bump into the limitations of this approach. You can find that the decisions on what to build next can be monopolised by the loud voice of one customer. Your product releases are focused on your customer’s project timescales. You can find you’re being given requirements focused on the how and what rather than why: missing out on problem discovery, limiting your ability to be really innovative with your solutions.

When Dayshape reached this point, we committed to pivoting to a product-first mindset. The key element of this was to ensure that all of our customers were able to run a version of Dayshape that was driven from a single, unified code base. We then transitioned all customers away from an expectation that they would be shipped a new version of Dayshape whenever they needed a new feature, and instead set out a reliable release cadence that customers could buy into.

Being on a single codebase means that every customer gets the benefit of the new development work that we invest in Dayshape, not just the features they request. For our team, we have fewer High Integrity Commitments each release, which leaves us freer to focus on what’s important now, rather than what was important when we signed a deal six months ago. And we can set product objectives and decide ourselves the best way to meet them, without having to go through change control with our customers.

Where we are now, and what the future holds

We didn’t wake up one morning and decide to transition from project-based work to product-led work. Our strategy evolved from a series of customer wins, and a gnawing sense that we could do better.

The way we serve our customers and help them to achieve their objectives has profoundly changed. Of course, with a new way of working comes a fresh set of challenges. We are continually striving to ensure our team shares experiences and learnings across the breadth of the business, regardless of which customer accounts are being worked on.

Building a scalable product with universal appeal is hard. Doing so whilst managing long-standing relationships which have developed within a different context is even harder. But, the way we see it, changing our approach and maturing as a business is an investment: in ourselves, our customers, and our people. And it’s one we’re proud to be making.

Interested in joining our growing team at the fastest growing tech company in Scotland? Check out our open roles here!

Related resources

See all insights