Services
Work
Blog
Team
Contact
Jobs
Beacon
Step
1
of
4
25%
About you
Please select the job role you most identify with
Product Management
Design / UX
Development / QA / Business Analyst
Leadership
Business size
Under 50
50 - 249
250 - 499
500 - 999
1,000 - 4,999
Over 5,000
Email
Purpose
2: Informed decision making
Decisions are often based on stakeholder intuition, opinions or assumptions of the founders/leader, and rarely on user research insights
Decisions are sometimes based on user research insights, but they’re not central to product decisions
Decisions are regularly based on relevant user research, with a strong customer or user centric mentality through-out the team
3: Roadmap
We don’t have an updated roadmap; we focus mainly on short-term & quick wins
We have a roadmap, but it’s focused on feature delivery or arbitrary goals, KPIs or milestones
Our roadmap is up-to-date and reviewed regularly; it’s objective & outcome focused and actively directs the team
4: Vision and mission
There isn’t a shared, aligned vision to guide the products. Teams aren’t aligned to the bigger picture and often work on projects / features without knowing how they connect to the vision or strategy
We have a vision, but it is not easily recollected by teams, and it isn’t used to drive product decisions
There is a clear vision that connects all product teams to the wider organisational strategy. It can easily be articulated by teams, working towards the north star
5: Prioritisation
Decisions are made from top-down with teams not involved and/or unsure why they have been made, often with last minute requests or outside agreed scope
Teams understand why prioritisation decisions have been made, but have little to no autonomy in deciding their own priorities or feasibility of delivery dates
Teams have autonomy to prioritise their own work against key results based on organisational objectives and company vision. Priorities incorporate feasible time estimates
6: Measurement
Products or features are launched without KPIs to measure their success
Products or features are launched with KPIs, but the team spends little time reviewing the results and iterating the product based on these
Products or features are launched with KPIs and are regularly monitored to track performance, with product improvements based directly on these
7: Market insight
Little research on the market (competitor research, industry & tech trends) is conducted
Some market research is conducted, but is not widely shared or reviewed by teams
Ongoing market research is taking place and shared with the product teams
8: Outcome led
Briefs to the product team are predetermined solutions, often instructing them how to solve the problem
Briefs are a mix between predetermined solutions and open-ended problems
Briefs are more often expressed as an open-ended problem, with desired outcomes, where the team is encouraged to find their own solutions
9: Product team influence
Product work is siloed and not shared with the wider company
Product is seen as important by the business, but not critical to the organisation’s overall strategy
Product is seen as equally as important as other areas of the business in terms of critical decision making
People
10: Product team cohesion
Teams aren’t confident to share opinions honestly, or there’s too much disagreement without mutual resolution, with silos within the team (between development, product and design)
There is some collaborative working and an open environment, but teams are reliant on rituals and tools to encourage this
Members of the product team have a naturally open and trusting feedback culture, work collaboratively together and resolve issues effectively
11: Accountability and clarity
There is uncertainty over roles and expectations of each other’s priorities / accountability
Team members know what’s expected of each other, but expectations aren’t always being met
Members of the product team have clearly defined roles, and their expectations are being met
12: People in the right seats
Product team members are spread thinly taking on responsibilities that shouldn’t be their remit
Mostly the right roles are fulfilled in the product team, but more hires are needed
All the roles needed in the product team are fulfilled, with appropriate specialists and a clear leadership structure in place
13: Product Training & skills development
There is no formal training or skills development provided
There is limited/ad hoc training and skills development
Teams have full access to ongoing programmes of training and development
14: Cross-team collaboration
Teams exist in siloed operation, with no cross-team collaboration across the organisation
There is some cross-team collaboration across the organisation, but often orchestrated by top-down leadership
Product teams collaborate naturally with colleagues from around the organisation at all levels of seniority
15: Team capacity
Team capacity is not measured, and no velocity metrics are known
Delivery velocity is available but often does not match roadmap expectations. Some limited time tracking and estimation processes and tools are in place.
Planning for delivery matches the capacity of the team. Members are rarely working over their scheduled time, and roadmap decisions match verifiable and realistic delivery timings.
Process
16: User Research methods
Little to no research methods are used in our organisation, as part of product development
We utilise one or two simple methods of user research, ad hoc or infrequently, which loosely inform the product development process
A wide range of qualitative and quantitative research methods are regularly used in our organisation, directly informing the product development process
17: User Research skill
Our team has little to no direct experience of practising user research
Some of our team, such as designers and product managers / owners, have some experience of basic user research techniques
We employ trained user research specialists, who conduct or coach research using robust research practices (i.e. clear hypotheses and eliminating bias)
18: Sharing research insights
There aren’t any research insights to share
User research insights are often not shared beyond the product team or the individual researcher
User research insights are widely accessible in the organisation, e.g. through a repository
19: Tools & systems
Access to tooling is restricted and limited
Some tools and systems are available to teams but seen as cost centres rather than value bases
People have access to the tools they need to help them communicate, collaborate, and do their job effectively
20: Design system
We don’t currently have a design system in place
The team follows some general design guidelines but there is also a lot of improvisation
A design system is in place to ensure consistency for the digital product ecosystem
21: Design process
Designers typically jump straight to high-fidelity UI designs, when we have a new feature to work on
Designers sometimes sketch, map out flows and ask for early feedback when we have a new feature to work on, before designing the final UI design
Designers regularly sketch, map out flows and iterate collaboratively with the product team on new features, before jumping straight to the final UI
22: Agility
Teams are not encouraged to change course of action based on new insights
Experimentation is part of the process, but the insights are often overruled or marked as nice to have
Teams are actively encouraged to experiment, fail fast and proceed with the best way forward
Δ