Buying Buy-in: A Startup Guide
The importance of team buy-in when building your product
Here’s a phrase that I bet every Product Team, small or large, has heard: “we need to get on the same page.” The thing is, everyone in the company is working towards the same end goal — or at least they should be. So why isn’t everyone on the same page? The answer isn’t exactly clear, but often times all that’s missing is a way for everyone to be kept in the loop. People like to know what is going on. And as more areas of the business become involved in the decision-making process, it’s even more important to get the entire team in agreement and on the same page. Problem-solving doesn’t exist in a vacuum, it needs to consider all the underlying factors of the business from the start: from engineers to operations to customer support to designers to the business side of the house. To get everyone in the same boat, you must first define and communicate the problems, goals, and needs. Otherwise, people around the office are going to look at you like this anytime you mention something:
Scoping Out Requests
Before improving Nudge Rewards’ methodologies for building products and communicating features, things around our office were often done on a need-to-know basis. But a couple months ago, the Product team at Nudge finally came up with our own way to properly communicate Feature Requests across the entire company. We’ve found the most successful approach begins with a Feature Sheet prepared by the Product Team to outline the feature specifications, followed by a few rounds of user acceptance testing after from the preliminary designs. Even for a one-person startup, it helps to have more than just a post-it note to keep you on track.
Feature Sheet
At Nudge Rewards, before we begin exploring the possibilities, our Product Team will prepare what we refer to as a Feature Sheet. The Feature Sheet is a dialogue document that outlines what we are accomplishing by building the Feature — it essentially acts as our spec sheet throughout the process. It helps the Product Team articulate to everyone else what the exact problem is that we’re solving for. When you are preparing a Feature Sheet you want to be specific. Where did this problem stem from? What is the biggest pain point you are solving for? What is the main user-benefit from the new feature? This isn’t simply for you to recall at a later date. The goal of the Feature Sheet is to gain team-wide buy-in on what exactly we are solving for, and what the solution will look like.
The Feature Sheet is done in a conversational writing style to feel more friendly and approachable; I’m not sure why we choose this approach, but it defiantly feels right; maybe the conversational style of writing makes it easier to explain to non-Product team members by already having the conversation planned in layman’s terms. Here, take a peek:
Nudge Rewards: Good news! We’re improving the way you interact with the Nudge feed.
User: Really? What are you doing to improve it?
Nudge Rewards: For starters, all employees, new or existing, will be able to catch up on Nudges for the current campaign that they haven’t seen yet. As well, you won’t have to have notifications turned on in order to receive Nudges.
User: Neat! How’s that going to work? What happens if I am added to the system mid campaign?
Nudge Rewards: As soon as you sign up, you’ll have all of the Nudges back to the start of the current campaign, so you’ll be able to catch up on everything that’s been going on.
Pretty simple, huh? Right on! The entire team is now in agreement of what is being solved, why it is being solved and the changes to come.
User Acceptance Testing
Once you’ve articulated the problem being solved, and framed it in a manner that the entire team understands, you’re ready to begin hashing out a solution aka finally getting into Sketch and doing your thing! After a couple of design iterations, a few Design Review meetings and, again, a couple of more design revisions, you should be here by now. The Feature Sheet above included an excerpt from the Nudge Feed Refactor Feature we released last week, so this is what your Sketch file might look like; a few views of awesomeness that align with your Feature Sheet.
We want to get this into the hands of the other team members to evaluate the designs and experience before we move forward with the development. The benefit to this approach is that every member of each team understands what is being built, and that everyone is in agreement, and that everyone has “bought-in”. The aim of User Acceptance Testing (UAT) is to test whether the design can handle the required tasks and actions that users will take. This should be completed as early into the Feature Process as possible in order to identify any flaws or areas for improvement that may cause additional development time down the road.
At Nudge Rewards, we’ve included a round of UAT into our Design Process in hopes to catch any flaws before starting the build. We include six engineers, a Product Manager, and a Designer (myself) to walkthrough a list of user scenarios. In the past we’ve included the Sales and Marketing folks, but that quickly became too big of a party (I know people say, too many cooks in a kitchen spoil the broth, and I believe it applies in this scenario).
Mockups & Storytelling
There is a fine line between making your mockups self contained, and telling a succinct story. Gaining buy-in requires you to paint the picture in a way where your team and stakeholders can envision how the feature will work. There are several stories that can be told, and you have to evaluate the various stories and corresponding behaviours in order to map out a mockup that tells all stories end to end. I am constantly pitching new designs to our Product team, and one thing I learned early on was how easily we can get fixated on false data, or “filler text”. This often comes up in discussions while doing design iterations; different screens are being sent out to various people prior to a meeting to have questions answered and now the mockup is left telling a disconnected story.
I allocate extra time to align our Marvel mockups to make sure that the complete story is being told, from end to end.
Recap
- The entire team needs to be in agreement to what is being built before the development begins
- Come up with a dialogue that can communicate the Feature spec to team members internally, and clients; we use a Feature Sheet to outline our specs
- Include a round of testing into the Design Process to ensure the designs can handle all of the required tasks and actions a user might perform
- Spend some additional time crafting a story that visually communicates the how the Feature will work, from end to end
I’d like to thank the entire team for their efforts, you can read about our other endeavours at https://medium.com/hitech-nudge-rewards.
