For those of you who have read my blog in the past, you know I write about what I am working on. Of late I have been writing product requirements for a new product you will hear about soon. You might be asking why a staffing company needs to write product requirements and how might one go about writing good product requirements, I hope I can enlighten you on both in this blog.
Let me first say that I spent most of my career as a product manager or a product marketing manager, not as a marketing communications manager. Meaning, I don’t come to marketing from the creative, event planning side, I come from the product/business side. After all these years, writing product requirements are easier for me than for many. I merely have the years in the chair and the practice. Writing product requirements are: a. not easy; b. time consuming; c. a bit painful at times. Writing product requirements requires a combination of skills: big picture thinking, but also thinking through the entire minutia of what one is trying to do. It takes discipline, practice, and lots of review.
Why Write Product Requirements
In the world of be careful of what you ask for, you might get it; I am writing product requirements for a product we will be rolling out in the fall. There is a product champion, but when I kept asking for product requirements, he wasn’t giving them to me. Then I had an “a ha” moment, he didn’t know what I was asking for, and I could keep on asking, but I wasn’t going to get anything. So I told him, I have finally realized, you aren’t going to get this written, because you aren’t focused on this, you are focused on something else. So, I will write the requirements and you can review them. So that’s what we did.
Why was I so insistent? Given this is a brand new product; we needed to make a lot of decisions on how we are going to deliver this product. As the head of marketing, I needed to be able to answer fundamental questions for you our constituents about:
• what is the product
• how will it be delivered
• how will you be able to buy it
• how will we follow up with you
• how will we communicate with you about the product
Without the product requirements, I couldn’t answer any of those questions. I couldn’t tell our web developers what to build, nor could I tell our marketing managers what to write about. This is why you need product requirements.
When I say product, it is any delivery of goods or services that your company provides. So this could in fact be a service and not a product. The service needs to be define, the markets served need to be defined and how the user is supposed to interface with the service needs to be defined.
What makes up good product requirements?
First let’s not confuse product requirements with product strategy. The product strategy comes first. With your product strategy you should be defining: the market size, potential customers, competitors, your strategic competitive advantage, your financial model for your new product, etc. Your product strategy should lay out all of the high levels fundamentals of why you are entering this business, or rolling out this new product or service.
Your product requirements should be largely defining to your organization the user experience and the details of how the product will be used. Product requirements should answer the question, what does the user do next? The user does this, and then this happens? It should define entries and exits, it should define follow ups and processes that you expect the user to take in buying your product or service or any other action the user might take or experience in its use.
The product requirements should define the look and feel of the product or service; it should define exactly what happens to the user at every step of the experience.
Here are some chapter headings that will help you create good product requirements:
Briefly describe the product, who it is for, the markets it will serve, the benefits of the product or service, etc. All of this should have been pulled from your product strategy
This is where you are going to start defining how the user will be working with/using the product. Remember, different user types could use the product in different ways. You need to define each and every way a user is going to interact with your service.
Based on the user scenarios that you have described, what happens to the user? As an example, if your product is a new website, your process flow should read something like this:
The user is directed to www.newwebsite.com from an email that was sent from marketing using Constant Contact. When the user arrives at www.newwebsite.com, they are asked to create a login and password. The create a login screen should ask the user to enter their email address and a password. The password should be required to be a “strong password.” Once the user creates the login and password, they are asked to create profile. The profile should include: Users name, company name, company address, phone number, email address, title, etc. Once that data is entered the user should be asked to review the information. The steps in the process for setting up the profile should be numbered so the user knows when they have reached the final screen.
Screen shots of other known processes are excellent guides for product requirements. I hope you can see from the above, the more detail, the better. Each user scenario should have its own process flow defined. The writer should always be asking his/herself the question of what comes next?
Every set of product requirements should define the testing of the user scenarios and the process flows. Even if brief, testing should include: Alpha Test, Beta Test and Final Inspection. There should be entry and exit criteria for each testing phase.
In our website example, if you have run through the testing phase, you would have had real users using the site that could provide valuable feedback on how they interfaced with the product. What I have learned over the years is that users always use the product or services in different ways than you think. Testing is required to understand those additional scenarios and to get feedback and make appropriate changes prior to launch.
The product requirements should include your launch plan. It should include following:
Communication plan – who are the people who need to be communicated about this launch, by whom and what is the message. Do not forget your internal staff in this communication strategy.
What is the method in which you will announce? – Are you going to announce this at a user conference, or send an email out, what are you going to do? Is there some event that will occur? You need to define all of this and describe who is involved.
There is announcement and then there is go live. Sometimes those are the same time, and sometimes not, this needs to be defined. You need to define all the steps that need to take place before the service goes live. You might have to train staff, or train external staff. You might have to have things printed. You might have to have all of your payment processing complete and certified, etc. You need to create a spreadsheet with dates and dependency of actions. Owners need to be assigned and routine updates need to occur prior to launch.
There might be additional things that need to happen that are not included in the product plan. Those should be defined in the action items.
Review, re-write, review, agree, assign takes, monitor, measure, make changes, re-write, stay on schedule, be aware of scope creep. Be diligent, be focused. Product plans are very specific. There might be a product plan for building the space shuttle, but I bet there is one specifically for the flight commander’s seat. Product plans should be that specific and that focused. If you cover too much, you will never be able to build and introduce the fantastic new product or service you want to bring to market.
This is obviously a very brief summary of how to write product requirements. There are many great guides out in the marketplace that can help you. But even if you do what is defined above, you will deliver a better product or service, sooner. Your staff will be informed and so will your customers. You will miss fewer steps and make fewer mistakes. Good luck! As always, feedback is welcome.