Briefing Teams on Product Development
This week, in our Product Management course, we were tasked with creating a Feature Brief of our banking application. Essentially, a Feature Brief is meant to serve as a presentation of the product development process and plan for all teams involved. It is meant to coalesce various teams from marketing to design to development to legal around the plan for how a product will come into existence.
Part of this involves telling the story of why it will come into existence to ensure teams are onboard and on the same page about why we are creating this product.
As such, my Feature Brief was broken in to 3 parts:
- Insights – this section provided insights gathered from research which helped inform why my application is needed
- Roadmap – this section explains the plan for how my application will come into existence at a high level, in a way that is applicable to most teams but not extremely directive to any
- Capabilities – this section outlines some of the core functionality of my application so that all teams can begin imagining app in its physical form and considering the mode by which they will be contributing to its development
I decided to develop my feature brief in Google Slides and then convert it to a PDF for presentation. For presentation in class, I printed and bound my Feature Brief. In all, it is 32 pages and you can view it here.
There were 4 steps involved in the creation of my brief.
Step 1: Find Out What Users Want
After working on my mobile application for nearly 3 months now, I have done two rounds of user interviews with 6 users each time. And, yet, as I set out to create this brief, I realized my interviews had been very specific to the flows I had been assigned. I was looking for specific feedback on features and screens within my application and had not been as interested in the usage of my application at large.
As a start, I decided to go back and listen to the recordings of the interviews I had held over the past couple of months. I found that often in the beginning of the interviews and a couple times throughout my participants revealed nuggets of their opinion about banking, banking specifically with Wells Fargo, and what a banking app “should do” (i.e. what features are most important). After pulling out these quotes and theming them, I was able to develop 4 core insights that help bolster my argument for creating an application and creating it in the way that I had:
- There is a mistrust amongst the general public around banking with Wells Fargo that persists into the relationship that Wells Fargo account holders have with their bank
- In their day-to-day interactions with their bank, Wells Fargo account holders are looking for unprovoked transparency to give them reassurance about their banking experience
- Account holders want to know how much money is in their account, where it came from, and where it went
- Account holders want to be able to easily move money, between accounts and into accounts (deposits)
If I had the foresight that I do now and time, I would certainly have conducted user testing in a different sequence and garnered different input from my users. At the beginning, I would have conducted interviews and contextual inquiry specifically focused on users experience at Wells Fargo, users experience banking in general, and what functionality was most desired in a banking app. Ideally then, I would be able to develop the flows which were most pertinent to users.
In this instance, we were assigned flows to develop. I imagine this is something that happens quite frequently in companies. If I had more time, at the point that I was assigned the flows, I would have conducted research to understand their value to a user before creating them to understand where they should fit into my concept map and how the information architecture should be developed. I would THEN conduct user testing on specific flows, screens, interactions, etc.
Step 2: Illustrating a Generalized Roadmap
For this assignment, I was assuming that Wells Fargo did not currently have a banking application (though they do). After identifying the insights that I did above, I explained the value of this solution to a user as a value proposition which read:
“This project will create a mobile application that allows account holders to have interaction with their bank at any time and in any place with ease.
It will supply them with the most necessary information they expect to get from their bank and allow them to complete the most essential tasks they would hope to complete on a desktop or during an average bank visit from the convenience of their mobile phone.”
The next step was outlining how the application would be developed. I did this by creating a generalized roadmap, which could be applied to multiple teams, of the application development.
After creating a roadmap for the developers who will be building my application a few weeks ago, I was able to work off of that to build my more generalized roadmap.
Drawing it out a few times first, I worked to create something that was complex enough to explain all that would go into the development of my app but simple enough to be applied across teams.
Step 3: Showing Off Capabilities
The next step was to illustrate some of the core capabilities of my app so that various teams could begin to imagine what the app will look like.
To do this, I highlighted various screens and called out some of the reasons I chose the functionality that I did which were aligned with the insights I used to create my app in the first place.
This process was a tough one as I worked to balance the fidelity of the screens I was sharing with the amount of screens I was showing and content about each screen that I was sharing. Knowing that most likely other teams will want to see high fidelity screens, it was an interesting exercise in learning where to place time and value and how to tell the story of where you are at in the design process without being finished.
If I were to create my Feature Brief over again, I would have made some of the earlier screens I shared high fidelity and then told a story in my Feature Brief about why the others were still wireframes, addressing the timeline by which I hoped to have all the designs and UI complete.
Step 4: Making It A Physical Thing
After outlining some of the core capabilities of my app, my Feature Brief was complete and the intention was to present it to our class, as if they were members of teams being briefed on this app at Wells Fargo. For this, I converted my Google Slides presentation in to PDF format and printed it on a color printer.
After printing the first copy, I needed to tweak the positioning of some text boxes and color to allow for things to appear clearly and accurately on paper (even if they appeared clearly and accurately in their digital format). This took printing a couple copies before everything was presented as it should be.
A number of my classmates opted to have their Feature Briefs printed and bound professionally. I decided I did not want to do that because I wanted my brief to be a living document that people felt comfortable writing on and wanted to give it a less complete and polished feel so others would be more inclined to give feedback. Since this was my first Feature Brief, I knew there would be errors and missteps in my narrative.
That being said, I wanted my document to have the feel of something somewhat formal, as if I were actually presenting it. I decided to bind my pages with something called a screw post. A quick Google search revealed that they sold them at a number of stores in town and it was just a matter of going to one to get them. Unfortunately, the first store I visited was sold out. The second had enough to bind two packets, but not the 5 that Scott had asked. Walmart told me they did not sell them, even though I had seen differently online. I even found that there is something similar made called a sex bolt and awkwardly had to asked a customer service rep named Charles if they may have any of those, if they did not carry screw posts.
In the end, I spent my entire afternoon visiting four stores and ended up with enough screw posts for two bound packets. This was a big learning for me. Small details like how you choose to print out something for a physical presentation can be a big part of peoples perception of your content. Allocating enough time for the process of printing and creating your physical documents is really important. It may be worth it in the end to pay a company to print and bind something for you to save that time cobbling resources together.