Your product organisation, assessed the way an investor would assess it.

Basis of assessment

Most product advice comes from people who have never had to judge a product team on someone else's money.

When a private equity firm is deciding whether to buy a software company, someone has to look at the product function and answer a hard question: will this organisation deliver the growth in the model, or won't it?

For the last four years, that has been my job. I have assessed product strategy, roadmap credibility, team structure, and the way decisions actually get made in more than a hundred software businesses as part of a wider technical due diligence process, then reported to an investor in writing, with the cost of remediation attached.

Before that I spent 25 years on the other side of it, leading product functions in cloud and enterprise software. So when I say a product organisation needs restructuring, I am not describing something I have read about.

That combination is the whole offer. I know what good looks like because I have had to grade it repeatedly, against real companies, with real money riding on the answer.

Scope of services

Indicators

The circumstances in which companies typically make contact.

• 3.1 Growth has outrun the way you work. The product function was built for a company a third of your size. It still runs on the founder's instinct, the loudest customer, and whatever is on fire. It worked, right up until it didn't.
• 3.2 There is a raise or a sale coming. Someone is going to assess your product organisation properly, probably within the year, and their findings will show up in a valuation. Better to know now, while there is time to act.
• 3.3 Ownership has just changed. Two product functions after an acquisition, two roadmaps, two sets of habits. Or new investors with a plan and a hundred days to show progress against it.

Product Maturity Assessment

Most companies have a rough sense that their product function could be better. Very few can say precisely where the gaps are, which ones cost the most, or what order to fix them in. That vagueness is expensive: effort goes to whatever is most visible rather than whatever matters most.

The framework is the one I use in diligence. The difference is timing. You get the findings while there is still time to act on them, rather than during a process when they become a valuation discussion.

4.2 The Ten Dimensions

01Product Organisation

Is the team shaped for the work, are the right roles present at the right seniority, and is ownership clear enough that decisions do not escalate by default?

02Strategy & Vision

Is there a coherent product strategy, is it understood beyond the leadership team, and does everything else visibly follow from it?

03Discovery & Innovation

How evidence from customers and the market reaches product decisions, and whether the team is finding problems or just collecting requests.

04Roadmap Credibility

Can this roadmap be delivered in the time claimed, and does it reach the commercial targets it exists to support?

05Prioritisation

How trade-offs get made, who makes them, and how much of the backlog reflects deliberate choice rather than accumulation.

06Ways of Working

How product and engineering actually work together, release cadence, and whether the process helps or is performed.

07New Product Introduction

What happens between code complete and a customer paying: launch readiness, enablement, pricing, and whether go-to-market is planned or improvised.

08Monitoring Adoption

What is measured after release, whether anyone acts on it, and whether success is defined before work starts rather than argued about afterwards.

09Product Tooling

The systems holding roadmap, backlog, feedback and analytics, and whether they give a single reliable picture or three conflicting ones.

10Portfolio Strategy

How products relate to each other, where investment is concentrated, and what is being sustained past the point it earns its place.

4.3 Method

• 4.3.1 Scoping call. What is prompting this, what you want covered, and what a useful answer looks like. No charge.
• 4.3.2 Discovery. Around a dozen structured interviews across product, engineering, sales, customer success and leadership, plus a review of your roadmaps, strategy documents, backlog and metrics.
• 4.3.3 Assessment. Each dimension scored against the benchmark, with the evidence behind the score.
• 4.3.4 Report and readout. A written report and a live session with your leadership team: findings, scores, and a prioritised remediation plan with effort and cost attached to each item.

4.4 Terms

• Duration. Three weeks from kick-off to readout.
• What I need. Access to your team's diaries, and honest conversations. Nothing else.
• Pricing. Scope depends on the size of your product organisation and how much ground you want covered, so pricing is agreed after a short call.

Consultancy

Not every situation needs a full assessment. Sometimes you already know what is wrong and need someone who has seen it before.

• 5.1 Product organisation design. The team has grown, the structure has not, and nobody is quite sure who owns what.
• 5.2 Product team performance. The team is busy and the output does not match. Usually prioritisation, clarity, or decision rights rather than effort.
• 5.3 Roadmap credibility. A roadmap you need to defend to a board, an investor, or a buyer. I will pressure-test it the way they will.
• 5.4 Hiring senior product leadership. Defining the need, writing the specification, and assessing candidates.
• 5.5 Mentoring product leaders. One-to-one with a Head of Product or first-time CPO who has stepped up quickly.

Engagements are scoped individually. Some run a fortnight, some run for months at a day or two a week.

Interim & fractional leadership

• Availability. Typically around two months' notice, though I can sometimes start sooner on a part-time basis while a fuller engagement is arranged.
• Working pattern. Remote-first, on site where it matters: kick-off, leadership sessions, and team work.
• Location. Based in Lincoln, working across the UK and Europe.

About

Neil Penny, Lincoln, UK

I started in software in the mid-nineties, in pre-sales, and moved into product management because I was more interested in why customers wanted things than in explaining how they worked.

Over the next 25 years, I led product functions for IT service management, governance, collaboration, risk and compliance, B2B integration and eInvoicing, and transport and logistics software companies. Teams of product managers, product owners, business analysts, and designers working alongside both small and large engineering teams.

In 2022, I moved into technical due diligence. As a Principal Practitioner at RingStone, I assess software companies on behalf of private equity investors, on deals from around £5m to close to $1bn. I've led over 100 engagements, both buy-side and sell-side, as well as product and organisation assessments, across Europe. That work continues.

Assessing 100+ product organisations in four years is an unusual education. You see the same failures repeatedly, in companies that look nothing alike, and you learn which ones actually matter.

I now bring that to software companies directly: assessment, consultancy, and interim leadership. Whether or not there's an investor in the picture, the problems are largely the same.

I live in historic Lincoln, a fantastic part of the country. Outside work, I play guitar and ukulele, badly; perform woodworking and DIY slowly; cycle, gym and golf rather too occasionally; and maintain a garden that's an ongoing negotiation with nature.