Product Facilitator? Wew, what’s that?
As part of my new laissez-faire approach to life and work I’ve taken a bit of a fluid approach to labelling my project roles. I had a look at what I was doing at Care Collective and decided ‘Product Facilitator’ pretty much summed it up.
UX doesn’t cut it anymore as this has become synonymous with front-end dev or visual design. Product owner doesn’t work as that also has existing connotations that don’t sit right.
UX doesn’t cut it anymore as this has become synonymous with front-end dev or visual design. Product owner doesn’t work as that also has existing connotations that don’t sit right.
Well what’s this project look like?
There’s no scope. There’s no requirements. There’s no product vision. All that exists is some keen people who want to improve the lives of people with disabilities. Perfect! I hate things that get in the way of getting real work done, but I love meaningful work with inspired people.
When I came in there were a set of wireframes vaguely communicating product concept, with a very undefined value proposition but some hypotheses. All good, we can work with this.
What does a ‘Product Facilitator’ do?
Well the title speaks for itself. Products don’t come out of thin air — someone has to come up with them. More often than not it’s someone sitting in an office somewhere at a lofty height issuing edicts.
But, unlike a product dictator, a product facilitator crafts a product concept and vision out of customer insights, customer feedback, the team’s ongoing involvement, and a bit of product genius (yeah. genius). We get there together.
A product facilitator crafts a product concept and vision out of customer insights, customer feedback, the team’s ongoing involvement, and a bit of product genius
A product vision or concept is the shared understanding you have with your team of what you’re going to build and how this helps the customer. The beating heart of your product. How it’s actually going to be useful — and not just an assumption, but a decent level of confidence across the team, because they’ve heard the customer stories directly, synthesised the insights together, workshopped and designed products and then torn them down with critiques and tests.
Nothing is ever 100%, but this is about as good as it gets.
… But what did you actually do?
Right. So besides figuring out where the team was, first item on the agenda was to immerse in our customers’ worlds.
Becoming an Insider
The team members all work in the industry, and have friends who have disabilities. In a way this led them to believe they knew about their customers, but when you probe a bit you quickly find out whether people really know. They had some knowledge, but they weren’t insiders.
What’s that mean? Well it’s simple. Do they really have a feeling for what these people go through as part of their lives? Here are some questions you really should be able to answer if you know your customer.
- What are some common behavioural patterns they exhibit to solve their problems?
- What’s their process look like and how do they feel about it? Where do they experience the most problems/get the best outcomes?
- What kind of questions do they have about how to solve their problems?
- What stories do they tell each other — either about bad experiences, or positive solutions to problems?
- Do you really feelingly connect with your customers?
You can’t answer these from a cursory outsider perspective. You need to immerse.
What did we do? We had some low-key extended coffee meetups, visited peer-to-peer groups and participated, attended information sessions and listened in facebook groups — as well as asking questions about how people did things. Like I said, it was great having team members who had ties into the community, totally invaluable.
And we began to see the answers to the above — we saw the strangely systemic behaviours and solutions to endemic problems. We heard the stories of difficulties and solutions. Light bulbs and product concepts naturally emerge from this kind of immersion.
The ever changing product concept
When I came in the team had a vague concept of their product. It was actually a combination of a few different product ideas and value props. We had to go through a bit of a process to get clarity and focus, because otherwise it’s like walking blindfolded — you get walk-shy and bump into things all the time.
Our unraveling and clarity process was as follows:
- pull out and define each product idea
- note down what customer insights or validation we have that points to whether this will be valuable
- rough team confidence around each product idea
- prioritise roughly in order of what the team wants to focus on
- next steps for each idea
This didn’t happen once, this was a continual process. Our product definitions changed each time we wrote the list for goodness sake. And this is good.
Constant critique and doubting
Sounds bad doesn’t it? Well this stuff goes on in people’s heads whether you want to hear it or not — so better have it out. Each person in the team has a valuable and relevant perspective and so it’s actually incredibly useful to constantly get the team to voice doubts about the product, and then re-shape it or seek more clarity or answer questions. This will increase team confidence, trust and engagement if done correctly.
We didn’t have a formal process for doing this as we were comfortable enough with each other and the process to just say it, but if you suspect that your team isn’t there yet you may want to try out a structured critique process such as ritual dissent. And do it daily.
Validation, Testing and Getting confidence
I want to just put it out there — you can never know for sure if your product will be successful. There is no way to ‘prove’ it will be. All you can hope to do with validation is get a sense for what the right direction is, and be incrementally building/learning/testing. And that’s not even the right order.
We did a variety of different things to validate. Validation needs to combine scientific and empirical approaches with intuitive sensibility.
Validation needs to combine scientific and empirical approaches with intuitive sensibility.
- We ran user tests with competing products that had similar product concepts. They were pretty shit actually, with all users preferring a google search. Probably why they haven’t taken off — but a great learning for us that there was something wrong with the way the product was shaped. We learned a lot from the google searches users did instead.
- Observing social groups that had formed to solve a problem. We noticed that there’d been a facebook group created specifically to solve a problem that we had a product idea for. This is pretty great validation — as you can see that people have enough of a problm that they are trying to find ways to solve this problem and are even using a semi-baked solution.
- Referring back to customer behaviours and problem-solving patterns. Our product ideas had to map back to user behaviours and needs. This was a constant source of validation and steering — and the whole team self-managed in this respect as we courted different product ideas because they all had a shared understanding of what we’d learned and were learning from customer research.
Yeah but when do you know if your product idea is ready?
Like I said, you never know.
We currently have a pretty decent product vision that we’re excited about. We’ve subjected it to rigorous critique, testing and matching to value props we know are needed.
Next step is to ramp up the validation — how cheaply can we get a semblance of a product up that we can test with users in real use?
Turns out pretty cheaply actually thanks to some (dodgy) wordpress wrangling, the fantastic wordpress plugin landscape and the amazing wordpress theme landscape.
We can whip up a product with most of the features we need for the cost of a theme and hosting, get grassroots participation and start engaging the community to get usage, feedback and a sense for whether this is the right direction.
We’re still in a state of uncertainty, we don’t know if this is it for sure, but we’re pretty excited and this feels like it could be a winner.
And that’s better than working to an edict and a list of requirements any day.