A little bit ago, Jeff Link from Built In was looking for Product Managers to share their actionable secrets to writing the best possible product requirements. I am honored to be one of the Product Managers that sat down with Jeff to provide my input. Jeff ended up publishing a great article on 7 tips for writing the best possible product requirement documents.
In an effort to boil down Jeff’s article even further, here are three actionable tips that can help your scrum team produce the best possible product requirements.
1. Know your “Customer”
As Product Managers we need to be strong advocates for the customer throughout the product development life-cycle. The more we can bring a customer mindset into the scrum team processes the better. Besides the end customer, you also need to be aware of other customers when it comes to Product requirements.
Beyond the end customer, stakeholders in your organization are another type of customer you need to keep in mind when writing Product requirements. This means looping them in to what you are planning, getting input once requirements are documented before engineering starts their work, and then circling back after a feature set is defined.
Software engineers on your team are also incredibly important as you build out requirement documents; they are going to be the main consumers of your documentation. Of course engineers need to understand enough about what you are looking to build, but also need to go beyond a baseline understanding. The more holistic view engineers have about why something is being built, the better chances they have in building a great product that works well for the end customer. Knowing the background and where you are going as a team can also result in
Proposals or ideas outside of the original scope that are technically possible with limited investment. Oftentimes, the return to the business here can be massive compared to the work needed because of the knowledge engineers can bring to technical feasibility.
Knowing when to cut the long tail of features. I’ve really enjoyed working with the team of engineers at Nordstrom on the product page for many reasons. The main reason is because they repeatedly identify points to cut the tail on work. There are times when the engineering team will deliver a layer of functionality that is not 100% aligned to the initial scope of the documented requirements. Instead they propose stopping work because the the “juice is no longer worth the squeeze” and we just can’t get as much value from the level of work required.
Here is a non tech example: Let’s say you work at a suit manufacturer, and that to make a whole suit it takes a team of tailors. Your team has been tasked with making a beautiful custom fit navy blue suit with three buttons. The team finishes the whole suit, except there was a shortage of buttons. After installing 2 out of 3 buttons the team has a choice; wait 2 weeks for a new shipment of buttons to come in, or check and see if the customer has flexibility on the end product.
A non agile team would never ask the customer, and would deliver their suit 2 weeks later than expected. An agile team (like the one I work with at Nordstrom), would check in with the Product Manager and WOAH, turns out the customer doesn’t care about the number of buttons, they just want to look snazzy for their brother's wedding this coming weekend. And as a result, a 3rd button is not needed and the order can be closed out on time/sooner than expected; freeing up time and resources.
2. Find a good middle ground
Closely tied to understanding your customer (I.E. engineers that will be consuming your requirements), finding a balance in terms of level of detail for your requirements is key.
I have seen many product managers that spend more than 70% of their total time building out complex and frankly impressive looking well researched requirement documents. They answer every question. They support each and every stance with as much data as you could ever need. But guess what?
I would bet money that less than 5% of those robust documents actually get read or consumed
In an agile organization, documents that are too long cannot be produced fast enough to keep up with the pace of change a fast moving organization should be keeping up with. While a Product Manager is spending the time building out a document like this, new customer findings are being uncovered, new customer needs are not being met, and stakeholders will continuously have more input
HOWEVER
I have also seen the inverse. I have seen many Product Managers that don’t give nearly enough context for their engineering team to actually pick up and deliver work, or enough detail for stakeholders to self serve to understand what the team is targeting.
A big piece that falls down here is a lack of data. Providing stakeholders and engineers with data can be critical, but data is also incredibly important during the analysis phase of any piece of work. Figuring out whether or not you should do a feature in the first place, even before requirements documentation is created or engineers attack an idea is essential.
Taking a balance with the amount of investment you as a Product Manager put into requirements documentation is key. Jeff Link calls this the Goldilocks rule. You don’t want too much documentation. You don’t want too little documentation. You want just the right amount.
Pro tip: Having trouble knowing whether or not you have the right amount of documentation? ASK FOR FEEDBACK EARLY AND OFTEN.
3. Bring the experts in the room
Connecting your engineers directly with knowledgeable stakeholders will be key to both building great product requirement documents AND great features.
Sure, when the time comes you as a Product Manager can block, tackle, and insulate your engineering team from features requests that haven't been properly researched or are unfounded. But once the team has decided to pick up a new feature, strive to not get in the way of efficient knowledge transfer between your team and other engineers, or stakeholder teams.
I am a big believer in bringing in honored guests during team grooming ceremonies. Use the first half of grooming to refine tickets and open ideas, but think about using the second half of grooming to bring in an outside stakeholder that can talk at length about a ticket or series of tickets and answer any questions the engineers may have. Getting the experts in the room significantly shortens your feedback loop from a week all the way down to getting the right information you need in a minute!
At Nordstrom, I’ve been working to get our SEO team in the room to bring greater context around different ways we were structuring our page data. The development team had a ton of questions most of which I unfortunately couldn’t answer. What would have normally taken days of back and forth as I worked to get answers, instead took minutes as we were able to get enough information to pick up the work by the end of the meeting.
Overall, great Product requirements are essential to any software development teams success. Through keeping your “customer” in mind, taking a balance with just the right amount of detail, and getting your engineers connected directly with key stakeholders to get their questions answered, you will be able to drive tremendous value to your scrum team, and end customer.
A note on corona:
These are challenging times. If you are still lucky enough to be employed, make sure you’re taking enough time for your mental health. It's during these strange times that we often have more room to try something new!
About the author:
Ben Staples has over 7 years of product management and product marketing eCommerce experience. He is currently employed at Nordstrom as a Senior Product Manager responsible for their product pages on Nordstrom.com. Previously, Ben was a Senior Product Manager for Trunk Club responsible for their iOS and Android apps. Ben started his Product career as a Product Manager for Vistaprint where he was responsible for their cart and Checkout experiences. Before leaving Vistaprint, Ben founded the Vistaprint Product Management guild with over 40 members. Learn more at www.Ben-Staples.com
I do product management consulting! Interested in finding out more? Want to get notified when my next product article comes out? Interested in getting into Product Management but don't know how? Want even more book recommendations?! Reach out!