Over the years, I’ve had the privilege of working with product and development professionals from around the globe. All have been highly motivated to succeed—and to have their company be successful and profitable. However, there is a critical juncture in every product-development process where many stumble: the handoff of the requirements to the development team. Here are seven tips to help make your next project more successful.
1. Build a Business Plan and Keep It Up to Date
As companies move to new development methods, they often feel that a detailed business plan is no longer necessary or as important. But “we’ll be done when we’re done” will not usually pass muster with leadership or get the funding your project requires. Yes, you should encourage flexibility to roll out products without constraining creativity. But you need to articulate the business goals of every project based on some initial expectations (date, cost, revenue, etc.).
Be mindful that priorities and market conditions will change mid-project, budgets will get cut, key people may leave the project and development may over- or under-commit. The initial business plan will justify the investment at the start of the project. However, you should also keep it updated throughout the project, including the latest internal and external changes, and communicate the business impacts to management.
There are cases where the project no longer makes business sense to complete. For example, if you missed the market window or the competition just made the entire project irrelevant. If you don’t have an up-to-date business plan, how do you make that call?
2. Give Designers What They Need: Context About the Market
To do their jobs and apply their innovative talents, designers need context around the description of the problem. When shifting from a traditional requirements approach (“The product shall …”) to a market- or user-based approach, many think that requirements are supposed to be written at a very high level. “The network operator has a problem if the network is overloaded.” But how does he get notified or want to be notified? How quickly does he need to be notified? Why does he need to be notified? What does it mean that the “network is overloaded”? Why does he care? How often does this occur? It’s not about writing requirements at a higher level; it’s about providing more context about the problem. Then the designer can own defining high-performing, well-architected solutions that provide a pleasing customer experience.
3. Remember that Development Is the Customer for Requirements
I once worked with a company that was debating whether their market requirements document (MRD) was to be written in Word or PowerPoint. I asked them, “How does development want to receive it?” Their answer: “We haven’t asked.” A requirement, or a group of them delivered in a backlog or MRD, is intended to build a bridge for communicating with your development team. They are the customer for the artifact. How do they want to receive them? In what syntax? What tools will they use? The product team owns the overall success of the product in the market, but the development team provides the technology solution to make that happen. Provide context, problems to solve and the acceptance criteria in the way that they can best receive and use them.
4. Deliver Requirements in an Iterative fashion; Don’t just Throw Over the Wall
Continually communicate the requirements with the team that will be defining and delivering the product. Don’t assume that the development team will read and understand all the requirements. Though this takes time, it will save huge effort in the long run. There are so many variables involved that product management must provide a forum for all to discuss them. What about this? And that? Who? How often? Why is this higher priority? What if we don’t do this one? Do you really mean that? What about all of our technical debt? These discussions need to be had at the beginning and throughout the project. Having the right people hashing through the detailed requirements, posing and discussing questions and getting a common understanding of the problems will not only encourage better teaming, but also allow you to deliver more innovative products in a shorter amount of time.
5. Write as Content, Not Syntax
A regular syntax today for requirements is the user story format. This has become very popular with the movement to iterative (Agile, Scrum, Lean, etc.) development techniques. Generally, user stories come in the following form: “As a role, I want to do something, so that I can accomplish a goal or objective.” In many cases, the user story syntax may be used to express a market-based requirement. But just because the requirement is written using the syntax doesn’t mean it’s a well-written requirement. “As a lab technician, I want to have a red ‘trouble’ button on my screen, so that I can do my job” is a poorly written requirement—yet it conforms to the user story syntax.
6. Focus on What, Not How
Requirements are “market requirements” not “product requirements.” The product team’s primary responsibility with development is to provide problems to be solved in the market—not product specifications. Too often, either out of ignorance or the desire to impose one’s technical opinion, requirements are written that prescribe how to build the product and not what the market problem is. For every requirement, ask yourself: Have I stepped over the line and given development a how instead of a what?
7. Have Some Fun and Make It a Team Sport
Lastly, defining and delivering products is what technology companies do. It should not be drudgery or viewed as a battle between the product team and development. Encourage some creativity in the process and have a little fun.
Just because companies have done away with sponsored beer blasts doesn’t mean we can’t go to a park or bar and have a weekly group happy hour. Give out awards for the most creative solutions to gnarly problems. Celebrate a release with music and cake.
Incorporate these seven tips in your next and all future projects, and you will find that your projects will run much more smoothly and deliver better outcomes overall.
