Seven dimensions framework

Product maturity assessment

This document gives a view into how product as a function is working at Vesper today and where the main opportunities lie.

Strength
Gap or risk

Does everyone understand where the company is going and why?

Strengths

Product team can articulate how their work connects to company OKRs. Developers can do this to a lesser extent, but the awareness is there.
Company direction is shared on a structured cadence: quarterly roadmap, six-weekly update, and bi-weekly product update where the team explains where the product is going and why.
Cross-functional tensions can be resolved quickly between the teams (Product/Tech with Commercial) when the situation requires it.
High level strategic context is high across the org.
Four-team topology organized around jobs-to-be-done, effective end of April 2026. Each team has a named PM, tech lead, and designer, which gives alignment a structural home.

Gaps and risks

Two major strategic decisions are open and waiting for CEO input: marketplace direction and potential M&A.

Are we consistently making good decisions for the business?

Strengths

Roadmap alignment happens every six weeks with commercial teams. Decisions are made together rather than handed down.
Teams operate against OKRs, which gives a shared frame for prioritization.

Gaps and risks

The team has room to be more explicit about disagree-and-commit, particularly at the individual contributor level. When multiple people across teams are involved in how to move forward on a project, decisions sometimes stay open longer than they should.
A decision log exists and is forming as a habit by some PMs. Needs to be more structural to be reliable for the broader organization.

Are we building the right solutions for our customers and the business?

Strengths

Discovery is a structured practice: a weekly discovery meeting and a discovery board in Jira. This is a real capability, not aspirational.
We have opportunity solution trees in active use, for example the Act and Learn OST.

Gaps and risks

Discovery rigor gaps into clarity on what problem you are trying to solve before jumping to solutions. Some PMs have this consistently; others do not.
Quite some of the reported discovery is solution discovery, not problem discovery.
Opportunity solution trees are not institutionalized consistently across teams.

Can our teams execute effectively, sustainably, and at pace?

Strengths

Teams are organized by customer journey, not function. This generally reduces hand-offs and keeps ownership clear.
Team compositions have been relatively stable (until the new set-up of the Web teams), which supports strong collaboration.
We have a product development lifecycle map that covers AI usage and the improvement initiatives across the full value chain from Discovery through Requirements, Design, Planning, Delivery, and Maintenance, plus a Meta guardrails layer.
An AI eval set is implemented for AI product outputs.
Design principles introduced by Vadym have been adopted as product principles across the team, this can be more consistent.

Gaps and risks

The AI-SDLC map is an activity list more than an outcome plan and not strongly tied to how it should increase metrics.
Small user counts and low frequency usage push teams toward feature delivery over outcome delivery. The goal is to make the teams more outcome oriented.
Cross-team alignment across Product & Tech teams occasionally drifts when multiple teams are involved in the same initiative. Known fixes exist (joint kickoff, a shared Slack channel) but are not yet applied consistently.
QA is often an afterthought on both the PM and dev side, with PMs doing QA as the default rather than a dedicated practice. This is an uncommon pattern and a process risk worth addressing.

Can we turn product delivery into measurable business value?

Strengths

Steps forward on release process: Kjell works with CS and Feiko (Product Marketing) on change communication for big deployments. For major releases, calendar invites are now sent in advance and the quarterly roadmap gives commercial teams forward visibility.
The bi-weekly product update gives clarity for the commercial teams on upcoming releases.
Adoption targets are set based on historical performance. When a target is missed, the team iterates on it.
Customer feedback loop is decently structured. Three components: direct customer conversations that are transcribed and turned into insights; a customer feedback channel; and a data issues channel.

Gaps and risks

Overall maturity on release process is still developing, there is still a big gap between shipped features and adopted across the customer base.
The customer feedback loop captures signal, but the loop back from product outcomes to the customer (did it get released?, did it actually help?) has not been closed.
The status of submitted feedback can be articulated more clearly.

Do we know whether product investment is paying off?

Strengths

Quarterly OKRs exist, tied to specific owners and tracked on a biweekly basis during the aquarium retro.
Product metrics have clear definitions, and we have a BI function that enables Product Managers to get insight from data and service other functions with dashboards and insights.

Gaps and risks

Measurement exists but the team needs more diligence on what the metrics mean and how to act on them. We are still missing a falsifiable hypothesis: if we ship X, then specific user will observable change within time, measured by metric.
There is an opportunity to improve the set of metrics that the product is steered on. The product has no overall north star metric and some metrics vary little over time.
There is a driver tree connecting product metrics to business outcomes, but this is not widely adopted.

Does the org have the capability and alignment required to succeed?

Strengths

Strong individual AI adoption from the majority of the team: Kjell, Devina, Daniel and Alejandro adopted Claude Code with light support; Vadym moved from hesitant to fully using AI prototyping.

Gaps and risks

Stakeholder management is a repeated gap across multiple PMs at different levels and in different forms. Needs to be treated as a team-level capability gap, not an individual issue.
The design-product-development triangle collaboration across the product development lifecycle is not at the desired level and consistently understood across the teams.
Span of control is an open structural question. Six direct reports limits the depth possible per person, which means capability gaps surface later than ideal. The decision between adding a management layer and promoting a lead PM needs to be made.
A few very knowledgeable senior people can mask the knowledge gaps of more junior team members. Worth watching for directly, for example by having the most senior person speak last in a discussion.