Photo by Fabricio Trujillo from Pexels

Product Ownership at Acorn

At Acorn we believe product development is a team sport. We are all here to win. We might play different roles, but we all have a common goal.

We also believe we are here to do more than simply write code or design interfaces — we are here to change the world of crowdfunding. Our vision at Acorn to is to create a crowdfunding platform which works for everyone by helping founders and startups find funding in a manner which is accessible, transparent and more likely to succeed.

This is a bold vision, and will take effort from everyone! Therefore we need the whole team to be playing to their fullest potential. That means we need a strong leader with the vision of the product they can share and collaborate with people from across the business (and beyond) to make the platform a reality.

The product role involves leadership, discovery and enabling delivery.

Therefore in this article we will explore the role of Product here at The Acorn Collective:

“Bringing people together to solve problems and grasp opportunities”

Leadership: Bringing people together

My role is to lead product delivery for our new crowdfunding platform —bringing development and the rest of the business together.

Being ‘product owner’ is a specific role I play, as a core member of the Scrum delivery team working closely with the development team, responsible for creating, maintaining and prioritising the team’s backlog of work, ensuring they understand it and it’s visible to the wider business.

However to do this effectively I play a larger role, working with other stakeholders in the business to distill the vision, negotiate requirements, validate assumptions and ask hard questions such as “why do we want that?” or “who will that benefit?” and “is that the right thing to build next?” or “is that the best way to build that?”

Some call this wider role ‘product manager’ whilst others consider it part of the ‘product owner’ role — either way it means I sit at the heart of platform development — but I won’t be doing it all myself!

“A black-and-white shot of an orchestra performing on stage in a concert hall” by Arindam Mahanta on Unsplash

Consider the difference between an orchestral conductor and a one-man band. The conductor combines and coordinates skilled autonomous musicians bringing together many instruments, each playing to their strengths. Whereas a ‘one-man band’ is a person trying to play as many instruments as they can simultaneously, using as many body parts as possible!

Whilst a one-man band can arguably be talented in their own way, the music from an orchestra led by a conductor is often richer and of a higher quality.

This is the skill of the product role — bringing together many individuals in harmonious synchrony to solve problems and grasp opportunities.

Discovery: Solving problems

My first primary objective is to ensure we are building the right thing at the right time. That means making a call very early on as to whether an opportunity should be pursued or not. The widespread adoption of agile methodologies and modern software engineering practices mean we can very easily find ourselves building and delivering the wrong things very quickly and efficiently — I’d much rather be using that effort on the right things than wasting it on the wrong things…

Work needs to be valuable. Value could be traditional ‘earning’ value, where we generate business value as a result of solving the problem. It could also be ‘learning’ value which helps us understand the problem or opportunities further. There is a chance it could also be a third type — ‘burning’ or ‘hype’ value where work is done to support marketing activities or gain exposure.

Therefore, through talking to users, stakeholders, designers and technical people we shall seek to understand the problems we face, and turn them into opportunities to deliver value to our users and maximise positive impact on our overall mission.

That means we need to fully understand the problems and opportunities presented to us.

Not every problem or opportunity will be clear to us. Many may be vague or embryonic and require further investigation, whereas others may be strongly held beliefs which require validation and challenge. Therefore we’ll need to employ a variety of discovery techniques to drill into the information we have, test hypotheses and challenge assumptions. We’ll want to eliminate as much ambiguity as possible so that we can go forward with confidence.

We’ll also want to ensure we fully appreciate the impact these opportunities will bring — that means understanding the perceived value and associated risk.

This will aid our prioritisation and handling of the work. If it’s valuable we’ll want to pursue it as soon as we can. If it’s high risk we’ll want to dedicate more thought or resource to it — and potentially tackle problems with higher risk first.

Then we want to explore the possible solutions and ideas open to us.

Some problems may have only one solution, but in reality there will be many solutions, or variations of a solution we could consider. Much of this will involve learning from our users and employing a variety of techniques to test ideas as efficiently as possible.

Additionally, each solution idea will need to be evaluated to ensure it is technically feasibility, usable, and remains valuable — i.e. the technical effort taken to create a usable product doesn’t wipe out any value it generates.

At any point we should not be afraid to park or even ditch the work if we decide it’s not worth pursuing.

Delivery: Grasping opportunities

My second primary objective is to ensure the delivery team have everything they need to work as efficiently and effectively as possible. This means I work hard to ensure I can look them in the eye with a solid understanding of the problem at hand and present a solution which they support, understand and can deliver.

In the dressing room…

In Scrum terms, this is ensuring the work is ‘ready’.

Here at Acorn this means:

  • Work is in a form which the delivery team can consume — be that stories, defects or spike requests — broken down into smaller units if required
  • We know the users affected, as well as the background and context in which the problem or opportunity lies
  • We know the value or impact of the delivering the work and how we’ll measure it
  • We know which solution we are pursuing, and why we chose that option
  • It has been sized by the development team
  • It has all the design and technical collateral and artefacts required for development
  • We know how we’ll demonstrate it to stakeholders
  • We know how we’ll test it
  • We understand the non-technical requirements and other cross-cutting concerns associated with the work

If we can get the right work this far, I’ll be very happy.

What remains is for me to support the team throughout the delivery as required, and provide them with user acceptance sign off when required. My objective here is to ensure the needs and solution remain understood as development progresses, and that we iron out any major feature or functionality clangers before it is demonstrated to any other interested parties, and certainly before it is deployed to the users!

Let the games begin…

We’ve understood the problem, explored solutions and chosen the right option to pursue. We’ve fleshed out our chosen solution and got it ready for delivery then out into the wild — what next?

Now the important work begins! Once solutions are built and delivered we need to measure what we’ve delivered to understand impact, and feed learnings back into our discovery and delivery funnels. This is especially important when working with ‘minimum viable’ iterations — we want to know how well our chosen slice of functionality is performing as efficiently as possible — how much are we learning, earning or burning (generating marketing hype)?

We want to focus on the outcomes, not the output.

But the fun doesn’t stop!

Are we heading in the right direction? What have we learnt? Are users signing up and using the platform? Are they staying? Are they inviting others to join them? Are they generating revenue?

Ultimately this is where product success is made or broken. If we’re measuring the right metrics we’ll know whether we are winning or losing, whether we can celebrate or need to try something else.

Here at Acorn we are looking forward to celebrating how we have changed the way founders and startups access funding. We know there will be many lessons to learn along the way, many beliefs to challenge and solutions to explore — but together as a team we are here to win!