0-1 in the UK energy sector... almost (part 1)

Prototyping to find product-market-fit, build key relationships, and lay the groundwork for an MVP.

Project summary

Over a six month period, I worked with Piclo's innovation lead, as well as colleagues from the wider energy industry, including UK government and Ofgem, to prototype and iterate on the vision for a new B2B SaaS product, designed to enable the trading of obligations to provide service in to various UK energy markets.

My role

• Running workshops with key stakeholders,
• Developing and iterating Figma prototypes,
• Desk-based research,
• Presenting to industry,
• Planning and facilitating qualitative end-user interviews.

Audience

UK-based energy providers and aggregators.

Problem

The UK's electricity grid is decarbonising as part of efforts to tackle climate change and move towards a more sustainable future. Companies that could provide greener power to the grid have been stymied in their efforts in part due to entrenched complexity, a fragmented ecosystem and low interoperability. This has had the effect of slowing the rate at which decarbonisation can happen.

In response to this incredibly large challenge, as part of a broader stream of innovation work, Piclo was awarded funding from UK Government and Innovate UK to develop an open and transparent marketplace enabling the trading of primary and secondary contracts. Our flagship SaaS product, Piclo Flex, was already tackling this head-on by enabling network operators to award primary local flexibility contracts at scale across their networks. But what about secondary trading? How could we leverage our market position and expertise to solve for this space too?

Ground-level

Through early conversations with potential end-users, we (myself and Piclo's innovation manager) learned that a key problem impacting secondary trading was a lack of visibility. Businesses needing to offload or wanting to procure certain types of second-hand contract had to rely on manual networking techniques such as calling or emailing peers from other organisations. This was slow and labour intensive, often leading to nothing happening at all. In addition, even if a successful trading partner was found, the process could fall down later for a variety of reasons, including:

• Lack of access to pricing data.
• Lack of contract standardisation.
• Strictness of market rules disallowing trading in some circumstances.

We chose to focus on the visibility problem initially due to prior experience solving in this space with our flagship SaaS app, PicloFlex.

Early discovery

This was a large and challenging project. The following represents a selection of key design discovery artefacts that will show the development of the work up to the point whereby we decided to build an MVP.

High-level service area model

I decided to create a simple, yet powerful service area model to help the team align around some common terminology, and act as a way for us to chunk down design development. Think of this is a simple diagram that plots out the top level sections of what could become a more detailed service blueprint down the line.

Why?

• Start aligning around common terminology for consistency.
• Think holistically from the start, so we can see what could be from high altitude. Start with some structure, even loosely held.
• Start lining up with service areas within our existing SaaS B2B app.
• Importantly, this also allowed us to think about the ground-level issues mentioned above in a wider context. This helped us begin mapping where in a potential user journey problems were impacting, and identify where we might focus our attention initially.

Establishing audience

Next, I spent some time with the team discussing various company archetypes that might be the most suitable customers to target for future research opportunities. We were considering the question: who might benefit most from our future secondary trading service, and why?

Within each, we also wanted to ensure we highlighted the different kinds of end users, their roles and potential concerns. You can only solve business problems by designing solutions for humans.

We were able to leverage experience and knowledge gained from building our current SaaS application, including prior research materials.

In addition to the above, I also interviewed our in-house commercial team to understand, of all the energy markets available, which might be most lucrative to our audience? Something we would corroborate later via user interviews.

Scenario mapping

Next, I lead the team through some speculative scenario mapping. This was initially done in-person and then taken in to Miro for further updates and feedback from the wider team.

Why?

• The challenge felt vast, and we weren't sure where to move next, this seemed like a good way to get the ball rolling.
• To align the team around a common overview of one potential customer journey.
• To surface useful knowledge the team already had and identify gaps.

Storyboarding

This was then adapted in to a storyboard, which I was able to use as a means to walk external stakeholders through what we were thinking. This was presented in-person to National Grid ESO at their headquarters in Warwick.

Why?

• This formed part of an initial relationship building exercise. We wanted National Grid ESO to be amendable to making updates to their technology that would unlock greater potential for us.
• The main goal here was better alignment between Piclo and National Grid ESO as to the potential of our collaboration, and provided a valuable source of feedback as to how things were working from their end.
• These were a great tool for communicating just enough detail to ensure any feedback was focussed on the right things.

Prototyping

Following feedback on the above, I next chose to create an interactive prototype that went through several rounds of iteration based on continued feedback.

Why?

• We wanted to create something more tangible we could use in conversations internally, and with potential end-users to start drilling down in to various details.
• This also allowed us to start spinning off some early thinking about product terminology, information architecture and lining that up with patterns from our exiting design system. This also served to help engineering colleagues begin planning a bit ahead of time should we proceed to build an MVP.

Zooming in a bit, I was able to leverage our existing component library to produce a mix of low to mid fidelity mockups. Within each prototype iteration we could vary the fidelity depending on our objectives (different audiences could provide feedback in different ways).

In the above, I was solving for a need to allow end-users to select specific parts of a contract to sell. For this type of contract, market rules allowed for certain windows of time to be transferred to another organisation. We didn't have a pre-existing pattern for this, so it made sense to focus on lower fidelity view for clarity and speed.

The next screenshot shows a higher fidelity view that we intended to use internally with senior management to re-affirm buy-in, as well as something we could use in sales decks with potential investors.

A major learning moment

At the outset of this post, I mentioned that we successfully identified a market vertical with potential for recurring revenue.

Initially, to this point, we had been focussed on a market called "STOR" or "Short Term Operating Reserve" - facilitated by National Grid ESO. This market was on the radar as we had some prior knowledge of it from earlier activities.

However, mid-way through the work we attended a webinar communicating business processes governing how National Grid ESO intended the market to work, which included the following slide:

For us to productise a secondary trading solution, we realised we'd need to take in to account the above market rules for transferring contracts between providers.

Moreover, we became concerned about the impact the rules would have on liquidity potential.

In response, alongside Piclo's innovation manager, I conducted some additional quant analysis of our existing customer base, after which we concluded that our hunch was correct. In some instances, we could see that there may only be 1 or 2 orgs that could trade with one another.

As a result, we decided to pause progressing design work for this specific market, and re-assess.

The key takeaway for us here was that we needed a better way to evaluate candidate markets before proceeding any further. We settled on the following (loosely held) factors:

• Potential scalability: number of technologies allowed to participate and equivalent markets outside the UK)
• Strictness of market rules and dependencies: how reliant would we be on third party orgs?
• Cadence of primary contracts being awarded: how likely is it that there could be regular recurring revenue?
• Existing activity and competition: is there already secondary trading happening, and is there any competition facilitating this already?
• Alignment with broader business mission and strategy: does it help decarbonisation?

After a short evaluation process we decided to change our focus to secondary trading within the UK Capacity Market for reasons as illustrated above.

Back on track

It was important to expedite adapting our research goals to focus on the new market vertical. Thankfully, at a high level what we wanted to learn was essentially still the same:

Next, we could focus on gathering participants.

In the capacity market, participants are a matter of public record. We could look at public data and correlate this against our customer-base to select participants we already had good relationships with. We did this because we were finding feedback loops to be quite long, and getting a response from people we knew allowed us to iterate more quickly.

We could further shortlist participants by screening against some simple criteria.

• Do we have a prior relationship or an "in" with that business?
• Is secondary trading in this market likely to be of high value to them?
• Does this org have prior experience of secondary trading?

The remainder of our research process at this point would consist of qualitative interviews with 1-2 staff members from the businesses we'd identified.

To aid these sessions, I wrote a conversation guide containing key questions we'd like to ask all participants.

We'd spend 30mins in Q&A and then approximately 20-30mins focussing on a gathering feedback on the latest version of our prototype.

Prototyping the future

At this point we also an an important milestone approaching.

As part of the innovation funding requirements, we had to attend and present updates at regular check-ins with a panel comprising people from government, Ofgem, National Grid ESO, and elsewhere.

I was tasked with taking everything we had learned to this point and producing a prototype that could demonstrate a clear vision for the future.

After showing this prototype to several colleagues to gather more feedback I determined that the prototype needed to do more to tell a clear story, not just of the key value-proposition, but to demonstrate what an end to end journey might look like, taking in to account solving for multiple challenges.

Not only that, but I'd made some UI choices that were also running counter to telling a clear story, and so decided to look to other platforms and services for inspiration.

Wrapping up part 1

At this stage, myself and Piclo's innovation manager had:

1. Worked through several stages of early discovery.
2. Spent a lot of time gathering feedback internally at Piclo, from end-users and other businesses in energy using qualitative interview techniques.
3. We'd experienced the need to pivot mid-way through, and made improvements to our process and thinking as a result.
4. We'd iterated through multiple prototypes and learned a lot about what our product would need to get right in order to be successful.
5. We'd developed strong relationships with end users with deep knowledge we could leverage to help improve our thinking.
6. We'd presented a cohesive vision to an industry panel to help further the project and build up Piclo's reputation as an innovator and important industry player.

Key victories

• We successfully identified a key market vertical with potential to generate recurring revenue.
• We successfully cultivated key relationships with colleagues at National Grid ESO, Ofgem, and from within our pool of end-user partners (that would pay off significantly later).
• We were able to refine and iterate a future-vision prototype, and gather enough feedback to the point whereby we had enough confidence to commence building an MVP.
• In our prototypes, I was able to successfully leverage design patterns from common B2C platforms to better sell the value-add of what we might build.

Reflections

• UK energy markets require deep levels of expertise to operate within successfully. Building this domain knowledge from a design perspective proved to be a significant challenge, something our broader team would wrestle with many times. Discussing this challenge with other design colleagues, we came up with the concept of "min viable knowledge" i.e. what is lowest level of expertise I need to develop in order to be able to make truly user-centric design choices? How might I approach that consistently? More granular research and learning goals?
• 0 to 1 projects can be uncertain and messy. There are lots of tools and frameworks out there that are used successfully and regularly to help expedite the process of driving success. How might I have leveraged those to move faster and arrive at successful outcomes sooner?

Next steps - validation

In line with overarching project milestones and requirements, we next wanted to take our prototype and build out an MVP that would allow us to perform some real-world end-to-end trades. The goal: validate the proposition and prove it's value - see part 2 of this project write-up.

Notes for hiring managers

• This project was part funded with innovation money from UK government, which required we worked to a particular set of milestones overseen by a steering group. This largely dictated a slower pace than you might see happening in a more typical early stage startup.
• User research notes, transcripts, quotes and other materials aren't shown here for a privacy reasons. They're also just not that interesting to look at.