Fleshing out a Feature: Collections
So you need a new feature for your product. It’s not one of those easyish ones like adding a welcome email to a sign-up. Usually, communicating that takes a few lines in a single story.
Let’s talk about Epics. The collection of Stories which makes up a fully fledged feature. Sometimes, this is something roadmapped from the beginning. A nugget of an idea in the head of one of the key stakeholders. I’ll be using an example of a feature I worked on, Collections, to bring a real-world narrative to this article.
What are your steps?
1. Do your research.
You need to deliver on this product. Maybe you’ve spent months getting to know its ins and outs, developing a detailed roadmap. It’s also possible you just started with minimal documentation and roadmap. That’s fine. Handle it.
Talk to Stakeholders
Who told you this feature is needed? Book a workshop with the stakeholders involved. Get out that whiteboard and mock-up your feature, what happens at what stage. Why does the stakeholder think this feature is necessary? What sort of research was done before you came on board?
This is discovery. Try keeping your group workshops small, to the point. It’s great to get different ideas, but important to stay on track. Smaller groups are easier to manage — this doesn’t have to be a debate.
Get your Customer Viewpoint
Got a group of superusers? The fanatics who use your product and evangelise it? No? Build that list. User communities are essential and vastly undervalued.
If you have that list, get their opinions. Split the feature into sub-features and present each to different groups of superusers. Ask their opinion and feedback.
Why split them up? A customer will often just agree a feature is a good idea and stop there. You don’t want this.
Constructive criticism is essential. So, they like one sub-feature, what makes it better? What do they expect to grow from this feature? What is needed to make their life easier?
Compare that list of ideas and feedback to your feature as a whole, does it live up to your customer expectations?
Doing this helped me.
I worked on a Learning Management System Social Network for Kindergarten teachers called FunLearning. When I started, one feature was heralded as essential, and that was Collections. Described to me as a way for users to save activities or articles to use or read later, and to be able to publish these to a board. Coincidentally, this was released as an app Collect by WeTransfer a few months after we rolled out with the feature for FunLearning.
So I found out more about the feature from the primary stakeholders, all founders, within the company — this is a key feature already pitched to current customers before I’d come onboard. Every stakeholder had a slightly different story of what the feature was, some detailed, some not so much.
So a group workshop didn’t work here. I spoke to each of them casually about Collections, see what they thought it was and what benefits it gives to the user. Many of the founders were extremely customer-facing, which is great — they know the teachers using the platform really want this feature. And they had insight to what the customers expected.
I later talked with some teachers who used FunLearning. After the first couple, where I explained the entire feature and watched as eyes glazed over, I needed to change tack. Focus on the tiny solutions, and see if they get excited and develop those solutions with fresh ideas, or even other aspects of Collections already on the list.
Collating all this information got me to where I could think out the logic and start mocking. I had customer and expert data. I knew it was a market need, a selling point for the product — people buy it because they know this feature is coming.
2. Mock it til it rocks
You’ve collated a bunch of feedback and suggestions together. Now use that data to understand how this feature works and why. You’ll become an expert in its justification, usefulness, logic flow, marketability, etc.
Draw it out if you haven’t already done so. Medium doesn’t matter.
Bring in your designer and developer. For me, it’s really important to discuss rather than tell. Designers, UI designers especially, tend to have a good idea of UX. Developers are probably the only ones who know the product on the inside better than you – their advice is essential.
Present your feature and workshop. Document ideas that come to the table and make sure they understand exactly what the intended user solution is. How it works grows from this.
I had an amazing team.
Collections allows teachers on FunLearning to “bookmark” content onto boards, much like Pinterest. They categorise the content as public or private and the boards likewise (this is important later).
They can share boards with their colleagues, but one of the key differentiators here is public link boards.
Teachers can give a link to their boards, and anybody with the link can see it, whether they’re registered or not. Only content categorised as public is shown, and that content only includes the content itself, not the user who posted it, or the comments and likes on the content.
To understand why, you need to think about how kindergarten teachers work. They have a drawer for different activities or activity categories — let’s say your structured day finishes early for a couple of kids, pulling out this drawer to keep them learning is the go-to solution. Collections digitises this drawer, but keeps teacher’s discussion about each piece of content or activity, private, in the staff room (or in this case FunLearning).
Teachers can also share boards amongst one another, so a teacher in Singapore could be using a Nature Learning Collection built by a teacher in Virginia.
With Collections, I had one workshop and a follow-up with my lead designer and lead developers. Between those a meeting with our CXO to go over the UX.
It gave everybody a chance, as investors of the product, to give input and improve the original idea I’d presented.
3. Be Agile.
Promises are made and broken. I think everybody would like to aspire to be the on-board shuttle group, but shit happens.
Developers need clarification, deadlines are looming and stress raises its head. This is the time for communication. And be flexible here. The developer could be asking a yes/no question which is a blocker for a multitude of stories, delaying the timeline. Foster clarity and timeliness in the team.
For this feature, the designer was in Saõ Paulo, developers in Lahti and Valencia, and I was in Helsinki or Hämeenlinna. So we used Slack. While I had standups running, which works great for blocker management, having easy discourse between developers and designers was essential. We had a channel for that and a channel for backend and frontend communication.
Quite a bit of it is social — when you’re all in different rooms, bringing on a self of togetherness is important. But, when clarification is needed it’s there. Instantly most of the time – this keeps everyone happy, informed, and to schedule.
I’d tested out a couple of methods before this, but this combination really worked for me when developing this feature. Was the feature better because of it? I’d think so. And we got good feedback on it too.
4. Final Thought
The Harvard Business Review talks about three types of product development process philosophies. And about emotional intelligence. My takeaway is that it takes a great deal of humility to be a Product Manager — you own and are passionate about making the product great, and you’re generally one of the products most avid users.
But you must understand that you don’t know best. The key is to take the advice of consumers, stakeholders, product teams and more. Make a judgement call on what will work, based on whatever data you have.