Updated on by Fraser Davidson
The product isn’t mine. The product is ours.
When my co-founder retired earlier this year we had an opportunity to rethink our strategy around product development and to rip up all of our previous processes. Nine months on I am delighted with the (evolving) new process and coherency of our SaaS product strategy.
So, what have we changed over the course of 2024?
Developing our SaaS Product Strategy
In Cyclr’s early years, we were firmly ‘founder-led’ in product direction and feature prioritisation. It was consultative across the team but somewhat dictatorial. This was an appropriate strategy for the early days of Cyclr because our market was new and we were first to market with an embedded iPaaS concept. Therefore, we needed to implement our initial vision.
However, this has now changed and we’ve made four key improvements to our product strategy.
Four Product Strategy Improvements
One: Capability Statements
As Founders, we were guilty of having a particular vision of what we wanted to achieve, but not necessarily documenting it in an easy-to-digest format. This isn’t referring to the specification but the RATIONALE for the development. Fast-forward nine months and we now have internally available capability statements for all to consume.
Capability statements are a formal document that summarises core competencies, achievements, and unique selling points. For instance, the core competencies, goals and unique selling points of a feature in development.
Two: Team Wide Contribution
In the past, the Founders would have sole ownership of the SaaS product and be responsible for the proposal of development projects. Instead, we’ve introduced processes so any team member can own and define a capability statement for SaaS development projects.
Three: Collaborative Prioritisation
As SaaS product owners and Founders, we would determine the prioritisation of new features, in other words when and how they would be rolled out.
Instead, we have adopted a much more collaborative prioritisation process. This process involves understanding and documenting the prioritisation ranking of each key team. These are mapped side by side and as a team we determine the order of development.
Four: Cross-Functional Input
In the past new features would be released for internal input and by this I mean critique, not QA. This was done towards the end of the development process, which I’ll admit we did get wrong. It’s not that we made mistakes particularly, it’s just that this inevitably slowed down releases. This is because great ideas were introduced by other teams through this critique process at the end that should have been factored in at the beginning of the development process.
Now, we have developed the process of cross-functional input into feature capability statements from the very start of the SaaS development process. As well as at regular intervals throughout the feature development process.
Who is a SaaS Product Owner?
As Founder, I remain tightly involved in Cyclr’s product direction, and my voice remains important. I retain responsibility for the macro decisions and overall direction of travel for both the company and the product.
However, it is no longer about a singular vision and the energy in our product roadmap through this new approach is palpable. Involvement is not onerous but the speed of decision-making and insight generated when the right group is brought together on a capability statement assessment is mindblowing.
I am unsure if we made this transition too late or just at the right time. But, it certainly wasn’t too early. My sentiment is that it was the right time because we had a change at the Founder level of the business and the maturing nature we are experiencing.
As I said above, at Cyclr the product is no longer mine, it is ours.
Does this approach resonate with you? Did you also go through a similar transition? Join the discussion on LinkedIn.
