For my current context (B2B SaaS) I think this is a good self-assessment for product development teams. I’m sure it somewhat resembles other assessments, but interestingly it was created by a product development team (I facilitated the activity and tried to help with word-smithing). They “owned” the approach, which went a long way towards the team using the tool (they created).

The team committed to take the assessment quarterly as part of their organic continuous improvement approach. The detailed results were kept private within the team, and were not used for any kind of performance management scheme, or management oversight. Changes in the “health score” (the average of the individual team member scores) served as the catalyst for conversations and experiments.

It is not appropriate for all environments. You’ll notice it has a bit more of a “product tilt”, which correctly represents this team, but will not represent all teams. With their permission I am sharing it here to inspire others to develop similar self-assessments.

• 1 — Strong Disagree
• 2 — Disagree
• 3 — Neither agree nor disagree
• 4 — Agree
• 5 — Strongly Agree

1. Customer Access. The team has direct access to customers/users/partners/stakeholders and can contact them directly to do research, discovery, testing, and validation. The team knows who they are building for and why
2. Measure and Act On Impact. The team measures the impact of what they deliver to customers, has direct access to that data, and regularly uses that qualitative and quantitative data to guide their product development efforts. Poorly performing “features” are routinely eliminated or improved
3. Aligned With Business Outcomes. The team aligns its work directly to business outcomes (e.g. new revenue, upsell, churn, customer satisfaction, adoption), and not to proxy variables (e.g. time to project completion, velocity, etc.) When business outcomes are potentially counterbalancing (e.g. revenue growth vs. churn), that balance is represented to avoid adverse impacts
4. Context and Focus. The team stays aligned with value streams and initiatives for long enough to develop meaningful familiarity with the problem space and technology options/stack. We are not playing whack-a-mole and project-hopping. We iterate to achieve great outcomes
5. Limited External Dependencies. The team is unhindered by external dependencies. Examples of external dependencies might include: operations/IT, quality assurance, external UX and design dependencies (we prefer these dedicated to the team), sales and marketing, stakeholder approvals, limited meeting space, other feature development teams, etc.
6. Tools and Resources. The team has timely and consistent access to the tools and resources it needs to do its work. If these tools are provided by outside resources, they are done so with minimal friction
7. Continuous Improvement. The team regularly conducts safe retrospectives with a skilled and unbiased facilitator. The team holds itself accountable for continuous improvement experiments, and regularly updates (and self-enforces/adapts) its working agreements.
8. Funding. The team understands their funding model, and avoids delivering complexity/capabilities/value streams that they will have difficulty maintaining and improving due to lack of resources. Team is adequately resourced to deliver on its commitments and initiatives
9. Standards. The team sets and self-enforces quality, craft, and collaboration standards
10. Complexity and Risk Management. The team monitors the accumulation/emergence of technical “debt”, has an economic model for prioritizing this debt based on current capability gaps, and regularly prioritizes debt “work-down” to limit adverse economic effects (e.g. rapidly lengthening lead times, reliability issues, lost opportunities)
11. Flow. The team measures lead time (from some early point of commitment to actual value delivery), limits work in progress, and avoids high utilization rates. All work is visualized on a physical or virtual board, including “small stuff”, maintenance activities, rework, and fixing defects
12. Sustainable. The team has sufficient time (and space) set aside for focused, thoughtful work without disruptions. Meetings are well run and valuable. The work schedule is sustainable
13. Safety. The team fosters a safe work environment: safe to learn, safe to fail, safe to take risks, safe to have diverse interests, safe to push back and dissent, safe to onboard new team members etc. Environment features a high level of psychological safety (and this source)
14. Celebration. The team celebrates its wins (meaningful wins, not success theater) and learns from its failures. The team is encouraged to experiment to find better solutions, and discover better ways of working given their current context
15. Coaching and Facilitation. Team members have access to coaching (for hard and soft skills), career development guidance, and conflict resolution assistance for challenging interpersonal situations Contact me directly (@johncutlefish on Twitter, or LinkedIn) if you’d like to chat about doing this with your own team.

Are you headed to Mind the Product in June? Let me know! Coffee?

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities. To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!