You know the saying have two ears and one mouth? Where are your ears? If you’re solely focused on listening to your external market, you’re missing out on making a key internal deliverable, and ultimately your product, the best it can be.
Think of all the things you can do around a product. You can conceptualize it, build it, sell it, maintain it, make in-house enhancements to it, partner with other organizations to supplement missing components, and so on. Product managers are innately tied to all things product, leading to a dizzying spectrum of things to do with any and all departments within an organization.
Understanding the market and taking the necessary time to objectively gather and analyze the perceptions of customers, prospects, and those actively shopping is critical to creating products that people will love (and buy ^_^).
But what about your internal product?
You know, those things consumed frequently by development, quality assurance, professional services and other critical stakeholders. Just as an end-user’s sentiment toward an organization develops as a result of his or her interaction with the product, interactions with requirements can affect a product’s overall success or failure. When left unchecked, pent-up frustrations with requirements can tear away at a release team’s ability to work together and trust one another.
Listen To The Market
Far before I ever wrote my first requirement, I listened to the endless flow of frustrations murmured between peers: “There isn’t enough detail here.” “I don’t know what I’m supposed to test.”
One day, I decided to sit down with folks representing the different teams consuming the requirements. I made sure to meet with them one-on-one, in hopes of getting opinions free of peer influence. I’ve heard a lot of folks doing market research talk about how inspiring and meaningful market research participation can be. Doing research with your internal market is no different.
In these short meetings, I learned a lot about how the requirements were being consumed and the daily challenges team members faced:
- Make sure to write requirements for the people who consume them. Focusing on each individual requirement and whether it is clear isn’t enough. A single feature may have many requirements listed. If this is the case, how is the flow from requirement to requirement? While the requirement writers believed how they listed out all the requirements were logical, those who had to execute off those requirements often found the documents extremely disjointed. In my case, the actual structure and ordering of each requirement did not match how teams were assigned to execute off them.
- Prototypes add missing context. Visually displaying an idea of how requirements can be lumped together and exist on a page can make often lofty concepts tangible. These investments are great resources to get creative juices flowing — a springboard for the team to collectively mold the starting point that the prototype represents into a fleshed out design.
- Let the voice of the market be heard. For every feature, make sure that you’re clearly letting your teams know what the problem is that the requirements are going toward solving. Further, let them know how you know this. How do you know this problem is a pervasive issue that should be built over all other possibilities? It’s easy for team members to question the validity or necessity of any requirement without this market context being provided.
- Show that you’re listening. It’s terrible to hear these stories about teams that don’t trust one another — teams that would rather execute off their idea of a requirement than asking questions to the requirements writer. I have to wonder why that is? Even when I asked team members about requirements, individuals often felt their needs weren’t being considered. Some were really surprised that I even cared enough to ask for their opinions.
After my first requirements document review with all key stakeholders, I let out a deep breath. Was it perfect? Of course not! But, I can happily report that I didn’t have any huge stumbles. Most importantly, I arrived to emails of appreciation from my team members the next day. Each had valued the quality of the requirements and my dedication to improve certain aspects to aid, and hopefully expedite, the team’s ability to consume and understand them.
Don’t forget your internal market. Improving requirements is only one small piece where their insights can help. Do your research! I am confident that you’ll uncover some interesting insights that will make your requirements and processes better, your products more marketable and your teams united.