Two roles that get confused
When a non-technical founder or business owner starts a software project, the advice they get is "you need someone technical on your side." True. But "someone technical" covers two very different jobs, and hiring the wrong one wastes money.
A product owner decides what the product does. They own the vision, turn business goals into a prioritised list of work, write the requirements, answer the developers' questions, test what comes back and report to you. Their job is to make sure the right thing gets built.
A CTO decides how it is built and by whom. They choose the technology, design the architecture, hire and lead developers and set engineering standards. A fractional CTO does this part-time for several companies. Their job is to make sure the thing is built well and the technical team is run well.
Both matter. The question is which one your project needs now.
The test: do you have engineers to lead?
If you have no technical staff and one product being built by a vendor or a contractor, a fractional CTO has nobody to lead and nothing to architect that the vendor is not already doing. What you are missing is someone to define the product, prioritise the work and keep the vendor honest. That is a product owner.
If you have, or are about to hire, your own developers, and the technology choices will shape the company for years, you need a CTO, fractional or otherwise. You will also still need a product owner, because a CTO who is also writing requirements and running acceptance testing is doing two jobs badly.
For most NZ small businesses commissioning their first portal, web app or internal system, the honest answer is: product owner first, CTO only if and when you build an internal team.
What goes wrong without a product owner
Applicable sees the same pattern in projects that have stalled:
- The developer asks a question, nobody answers for a week and they guess.
- Features are added mid-build because nobody was ranking them, and the budget goes with them.
- The first time the owner sees the software is at the end, and it is not what they meant.
- Progress reports are technical and the owner cannot tell whether things are on track.
- Testing is done by the developer, so the bugs turn up with customers.
None of these are engineering problems. A fractional CTO would not fix them. A product owner would.
What a Virtual Product Owner gives you
Applicable's Virtual Product Owner is a senior person who takes the product owner role on a monthly retainer, sized in days per month. They own the vision, run the backlog, write the requirements, liaise with developers and vendors, manage the budget and run user acceptance testing with your own staff. It works whether Applicable is building or another vendor is.
Where a project does need technology strategy decisions, the Virtual Product Owner brings in the right technical lead for that decision rather than charging you for one permanently. Applicable is led by John Halvorsen-Jones, with more than 30 years in technology leadership, so the strategic view is on hand when it is needed.
When you do need a fractional CTO
There are real cases:
- You are hiring developers and need someone to interview, lead and set standards.
- Your product's technical design is itself the business risk, for example a platform many customers will run on.
- You are raising investment and investors want a named technical leader.
- You have inherited a codebase and need an independent view of whether to keep it.
For projects of that shape and scale, Applicable will say so and point you to a partner that works at that level. For the far more common case of one product, one vendor and a non-technical owner, the product owner is the role that moves the project.
Cost comparison
A fractional CTO in NZ is typically engaged for a set number of days a month at senior consulting rates. A Virtual Product Owner is engaged the same way, and because the role is closer to the day-to-day work it usually needs more hours than a CTO would but at a lower daily rate. Either way, ask for the days per month and the rate in writing, with no fixed term. Applicable prices the Virtual Product Owner that way and reviews it as the project changes.
Key takeaways
- A product owner decides what gets built and in what order; a CTO decides how it is built and leads the engineers.
- A non-technical owner with one product and a vendor needs a product owner first; a fractional CTO only makes sense once there are technical staff to lead.
- Stalled small business software projects usually fail on unanswered questions, unranked features and untested releases, which a product owner fixes.
- Applicable's Virtual Product Owner covers the product owner role on a monthly retainer, with technical strategy brought in when a decision needs it.