Designing for the Enterprise
Point Tools vs. Solutions
For a number of years most of our design and engineering effort was focused on creating Ingeniously Simple point tools for small to medium-sized businesses (SMBs); where a point tool could be defined as:
“A specific piece of software that was conceived to solve a specific end-user problem.”
Over the past couple of years however, Redgate has focused more of its effort towards how we might also serve and address the needs of our larger, enterprise customers. So, as we seek to answer this question, in this post I’ll be describing how we’re adjusting our mindset and approach towards research and design, so as to better cater to this high-end market.
To support this transition and model our behaviours around a new category of offering, we’ve had to make a distinction between point tools or stand-alone products and solutions, in terms of how we organise our portfolio, structure our product teams and communicate across the business. A Solution, therefore, can be described as:
“A product, service, or collection of products and services, designed with the intent of helping organisations make progress towards their desired outcomes.”
So how does this distinction impact and influence our design efforts?
The job of a Designer (and those doing research and design) for a given Solution is to first and foremost understand and design for the needs of both buyers and end-users in these larger and more complex organisations.
We have a responsibility to articulate the ‘why’ behind these many and varying sets needs:
- Those that are more prevalent during purchase or renewal discussions and relate to how they might evaluate and compare you as a vendor e.g. security, integration and support
- Those that might enable folks responsible for roll-out and adoption of the solution to demonstrate success year-on-year e.g. reports, dashboards, KPI tracking
- Those that speak to the core, functional value of your offering and its utility for end-users during consumption e.g. workflows, capabilities and features
At the highest level, we have a job to understand the bigger challenges and goals these organisations are looking to Redgate for help with and how we can enable them to reliably succeed and demonstrate that success over the lifetime of the relationship.
Principles of Enterprise Design
To help us work through the differences of designing for the enterprise (as compared to SMBs), we can distil this down into a few key principles or considerations:
1. Complexity of the customer journey
In a typical download-try-buy scenario, where the buyer is often the end-user, the customer journey is reasonably simple. A customer has a problem, identifies how and where one of our products might help, downloads and installs a trial and hopefully goes on to purchase.
In an enterprise scenario, however, there are often multiple stakeholders involved in a much larger, more complex purchasing decisions. Given the technical nature of these solutions and the need to integrate with (or adapt) their existing systems, process and tooling, there are often a number of additional stages in the journey to consider and design for.
For example, large organisations will spend considerably more time pre-purchase evaluating, trialling and configuring the solution to ensure it will meet their needs, and post-purchase will likely need far more support to manage the roll-out, training and adoption of the solution by its employees.
2. Transformational and transactional value
When evaluating a stand-alone product, as compared to an enterprise solution, there is likely to be differing expectations in terms of perceived and actual value.
For stand-alone products, these are expected to deliver more momentary or transactional value; such as speeding up a repetitive, routine task or entirely automating (or entirely eradicating the need for) an otherwise manual process.
In comparison, a high-end solution is expected to deliver more lasting or transformational value, such as improving an organisation’s development practices, reducing their operating costs and increasing the frequency of their releases.
3. Extending the customer relationship
The length of the engagement and more importantly, expectations of a larger organisation as it enters into a relationship with you, the vendor, are likely to be different from those of smaller businesses. Given the costs associated with setup, training, rollout and the solution itself, there is an immediate expectation of a level of commitment, well beyond this initial purchase.
You’ve built a level of trust as the vendor and now the switching costs are high for the organisation. They need to see a return on their investment and ultimately develop trust and faith in you as a brand.
There is an expectation that a vendor will work with them closely to understand both their current and future challenges and share a vision for how your portfolio of products and services will evolve over time to support current and future needs.
4. Multiple stakeholders, differing goals and needs
In an enterprise context, we see a necessary blend of engagement with both buyers and end-users. Where we once just concerned ourselves with the needs of end-users and their direct interactions with our software, we now have to consider multiple sets of needs across these different and diverse groups.
Notably, those who do engage directly with our software and have specific expectations around what it should do for them and those who are responsible for evaluating and purchasing the software, on behalf of this wider pool of end-users.
Buyers tend to think less about the specifics of what the software should do for them, but rather how and to what extent it will help their teams make progress towards a wider set of department-wide or organisational goals.
5. The solution is the sum of its parts
Moving away from a single product mindset has required us to think and start designing outside of the typical boundaries of traditional team structure. One team, one product, through a bottom-up lense.
We’ve needed to consciously break out of these silos with our research and design efforts to understand what a solution, and all its constituent parts, would need to offer to support their bigger Jobs to be Done; enabling larger customers to succeed and Redgate to continue to innovate in the ways in which we seek to address these jobs.
The scope for those working in these areas is set to encourage them to think outside of more traditional product boundaries, and even the concept of a product; affording them the ability to pull in the range of possible capabilities and services that will, in the future, address more of their jobs and/or serve them better than our competitors.
Fully embedded vs. Group model
One of the things we are trying this year to support this change and address some of the organisational design challenges is moving from a distributed, one-designer-per-team model, to the concept of Design Groups.
Where the intention is that a group, comprising of a handful of Product Designers, each with varying skills and interests, can better support the range of research and design needs across the entire solution.
Fully-embedded model
In our traditional setup, using the example illustrated below, we’d have three generalists fully embedded in individual products teams; where it was assumed that they would collaborate to make good design decisions on behalf of the solution. Yet each had their own product responsibilities and team objectives, diminishing both the time and impetus to collaborate, share research insights and think about the experience beyond their individual products.
Design group model
In the groups model, we’re attempting to break the silos described above and are experimenting with abstracting designers to create a team that operates across the entire solution. Their focus is strongly around collaboration and collectively supporting the teams that comprise the solution; identifying where they can have the greatest impact and designing a more holistic customer experience.
In addition to tackling these challenges around the scope and complexity of enterprise design, and the fundamental need for greater collaboration, we’ve also identified a number of other, secondary benefits we hope to realise from this experiment:
- Play to relative strengths and interests of generalists
- Support a range of design needs (strategy to execution)
- Identify and prioritise where design can add the most value
- Promotes consistency of design choices across the solution
- Can focus on quality vs. being spread too thin
- Reduce the risk of duplicating research efforts
- A shared understanding of Personas & Jobs to be Done
Whilst we’re by no means unique in the challenges we face in designing for a diverse and growing customer base (from small shops to large, glocal corporations) this does mark a change in how we approach research and design, the potential scope and scale of some of the design challenges we’ll face in future and how we organise and coordinate our design efforts.
If you’re thinking about your next career move or are looking for an exciting new opportunity in the field of design, take a look at our current Product Design vacancies on the Redgate careers page.
