Sometimes it's hard to know if we're doing things right. Do we have the right combination of tools to deliver the engagement outcomes we want for our supporters? Are they integrated properly with all the right data getting to the places where it's needed? And what about staffing - are our technology teams right-sized for what we're trying to achieve?
To help answer that last question I've created a tool called the Product Complexity Model.
Internal vs External Control
The Product Complexity Model helps us to assess what level of staffing is required for the platforms in a technology ecosystem, by mapping them against two axes - the level of internal vs external control, and the complexity of the product in question.
Internal vs external control asks the question:"to what extent do we have input over the development roadmap for this tool?". Products we work with will range from turnkey solutions performing simple functions to platforms built in-house requiring full development teams. A social media tool like Facebook, Twitter, or TikTok will offer little to no ability to customise the product, and customers have zero influence over decisions about how the product will develop and change over time. We've all been impacted by unexpected and unexplained changes in those algorithms right?
At the other end of the scale, an organisation may be building and developing a product from the ground up, creating a completely new tool built out on coding frameworks - but that is more unusual in the non-profit world where we are mostly consumers of technology.
However, over the last decade there has been a trend to deliver technology tools that offer significant room for customisation and additional development, even in areas that were previously very rigid, such as CRM. If your organisation is building a website on Wordpress, managing supporter relationships through a CRM like Salesforce or Microsoft Dynamics, or delivering complex business intelligence through a data lake solution, then it is increasingly the case that non-profits at scale are building internal development teams to handle this.
At this level, where the product development is highly internally controlled, there will need to be proper management of a backlog, with someone in charge of defining the vision and setting the roadmap for how the tool will improve over time.
Complexity
The complexity of a product is defined by the number of features and the extent to which it requires effort to manage. A simple tool that performs one task and is managed externally is low complexity - think of something like MIRO or Zoom. A complex tool is something with many features that would likely require specialist training to make the the best use of it. Think of business intelligence tools such as Tableau or PowerBI, or a digital marketing platform like Marketing Cloud or Hubspot.
The more complex a tool is, the more support people will need to help them maximise its value, whether that's training delivery, or creating a peer network to share knowledge, ideas, and enthusiasm.
Let's take a look at a few typical non-profit products mapped out against the model:
Staffing for Complexity - Low to High
The Product Complexity Model identifies functions that are required to manage the product within the ecosystem. For less-complex products it’s quite probable that several of these functions may be held by a single individual, for example, a non-profit organisation I worked with had a one person acting as Community Manager, Product Support, and Vendor Liaison for Engaging Networks - although that was a bit of a stretch for this particular system!
At the most basic level, any product which is invoiced to an organisation requires a person who can act as vendor liaison, ensuring that the bills are checked and paid appropriately. Although this is not a job role!
As a product becomes well utilised around the network the first key job role is Community Manager, a person who helps practitioners to get the most from their tools by generating strong connections amongst the collective and with the vendor.
If the product is technically challenging to use this may be followed by a Support Team, who augment any support offered by the vendor and help to educate users on how best to leverage the tool in the specific context of the organisation.
The next key role is that of Product Manager. Once a system has sufficient utilisation around a network (i.e. lots of people are using it), and/or is significantly under internal control, and/or is a critical part of organisational strategy, it becomes necessary to have someone on staff who can take responsibility for the product vision and ensure it develops in the best way possible according to the needs of the stakeholders.
The function of QA testing becomes relevant where a platform has a high output of new features. This allows us to ensure that product is not released that is buggy or problematic, which significantly impacts on user satisfaction. In the case that development is delivered by a vendor or partner it becomes a task of user acceptance testing (UAT) which can be coordinated with the practitioners by the Community Manager, but for an in-house tool this can require a full time QA Engineer who builds out automated testing suites using tools such as Behat or Selinium.
At the highest level of complexity and internal control we need to put in place full product development teams, ready to manage an active backlog and work within the Scrum methodology. The scale of any such team will depend on the complexity of the product, but would at minimum require a Product Owner (as an extension of the Product Manager role) and a Technical Architect. To this can be added Designers, Scrum Masters, Business Analysts, QA Engineers and developers as appropriate.
Next Steps
If you're interested to find out more about the Product Complexity Model, or you'd like to arrange a workshop to assess your current ecosystem of technology platforms using this tool then you can reach out to me directly using the contact form below.
The workshop usually takes about 90mins and requires some thinking in advance from your teams about what products you have and who is in charge of managing them.
We would bring together the existing product owners and key business stakeholders to map the products against the grid, and assess how the results match up to existing staffing, with a follow-up assessment to outline key gaps and potential solutions.
This sort of knowledge could potentially be very useful in helping you to pull together a business case for additional budget or staffing headcount the next time your organisation enters a strategic planning cycle.
If you’re interested in discussing product management at your organisation, or commissioning a product complexity review, D1VERG3NT Consulting would be delighted to have a conversation about your needs. Just get in touch!
Cover photo by John Barkiple on Unsplash
Comments