Product brief
One of the most essential tools for any app dev project is the product brief. The product manager compiles, updates, and maintains this document, but the entire team contributes to it. It serves as a single source of truth that’s easily accessible and that anyone from the administrative, business, or creative teams can reference. When in doubt, check the product brief.
This document outlines the project details, including the key stakeholders, team members, technical requirements, and more. It also provides high-level direction through sections like the hypothesis/vision statement and the user story, a summary of the problem and solution in terms of expected outcome (“X will result in Y”).
To help you get started with your product brief, we’ve provided this free template. You should also keep these principles in mind:
- Use precise language
- Keep it short
- Set the direction
- Include images, such as flow maps and wireframes
- Solicit feedback
Remember, the product brief’s purpose is to have everyone start on the same page and to keep them there.
As for user stories, these describe how the proposed product works in audience-friendly language. Typically, there are two main types of user stories: agile and narrative.
We recommend the agile story format, which provides high-level direction and shares the who, what, and why of the app. For instance, “As a [user type], I want to [see something, take some action] so that I can [goal, benefit].”
Here that is, translated to a real-world example: “As a sales rep, I want to be able to sort leads according to different criteria to find the most promising prospects and progress more deals.”
A narrative user story goes into much more granular detail, providing a vivid picture of the ideal workflow. It helps you envision what it would be like for someone to use the app, from the moment they open the homepage to whatever they do before they log off. And it helps orient anyone joining the project later.
Change management
If you’ve worked in product development for any amount of time, you know that there’s one undeniable truth: things are going to change along the way. That’s why we recommend the agile methodology and developing a change management framework from the beginning. If you wait until the end, it’s an uphill battle.
Whether the required changes are as small as a minor adjustment to some functionality within the UI or as major as a complete overhaul of the business case for the app’s overall direction, approach the change management process in a way that’s thoughtful, calculated, and measured. It may be agile, but it’s not impulsive; a bit of forethought goes a long way towards avoiding confusion and conflict.
The 7 Rs of change management provide a checklist of important points to consider while raising a change request:
Outcome setting and measuring
Having alignment on outcomes is critical to success. While this is somewhat covered in the Project Success Criteria section at the end of the product brief template we shared, we recommend also creating a document that lays out this information in more granular detail.
Start by defining the desired outcomes. These should be both quantitative and qualitative. The former include metrics that will serve as your key performance indicators (KPIs), such as improved app adoption, a reduction in time spent on a given task, or a direct ROI through closing more deals.
Here’s one example. Skuid customer FullSkope needed to provide banks with a loan product for businesses applying to the U.S. Small Business Association’s Paycheck Protection Program at the onset of the pandemic. Applications processed through their system led to more than $250 million in disbursed loans to small businesses.
Qualitative metrics, on the other hand, refer more to sentiments, such as how a user feels about an application, how easy or intuitive they find it, or whether they think it better addresses their needs.
Once you know what you’re looking for, it’s time to take baseline measurements. This is essential for proving ROI.
For example, Skuid customer Tapjoy created an app and dashboard view that resulted in processing weekly case files seven times faster. But before setting out, they measured their baseline: the original process took 3.5 hours. Since building an app using Skuid, the streamlined process only takes 30 minutes, which is paying great dividends to the company.
As part of taking baseline measurements, survey your users. That could mean fully anonymizing the survey (to relieve social pressure), hiring an unbiased third party, or bringing in someone from another part of the organization to conduct interviews. Once you have the results, publish them in a way that encourages continued honesty.
As you move throughout the product lifecycle, keep these desired outcomes top of mind. Every decision you make should be in service of achieving these goals.
Finally, you need a strategy for measuring results. After your app goes live, you should periodically survey users and find out how much the new product affects the desired outcomes, including both qualitative and quantitative results.
Ultimately, these measurements will serve as the baseline for your next iteration. Building a product is never a one-and-done project; continue to improve on the solution as necessary.