If you look at the role of requirements in a business, there is obvious value: expectations and goals are managed properly, work is organized and documented for effective communication, business reasoning and value is used to shape the software a business needs to do what it does best. However, there are times when business analysis and product management methodologies can be used for fun, or in this case, for the beginning of a great quest.
These days the world is full of entrepreneurs, from children operating a lemonade stand to the college freshman designing the next huge web obsession in his dorm room. It’s a wide and chaotic realm of high-level ideas and textbooks full of unknowns. But just because it isn’t a large money-making machine doesn’t mean it couldn’t benefit from a little bit of forethought, especially for upstart technology entrepreneurs looking to hone their product ideas.
The RML visual models offer a fantastic suite of tools to help anyone looking to plan out their big million billion dollar product idea. These are tools that can establish exactly what you hope to accomplish with your product, what you expect to come out of it, the definition of your minimum viable product, and the legwork that can be done ahead of development of a prototype. A single person with enough time could utilize RML to craft exactly what they’re looking for, and use it as a guide for their own personal development, or can be used to provide an immense amount of context and vision to a developer.
Typically the Business Objectives Model (BOM) is best utilized in scenarios where there are problems that need to be solved. They say that necessity is the mother of invention. Well, that necessity is your business problem. Using this will help you identify features you want to consider for your initial product. For our example in this blog post we’re going to pretend that we are a forlorn sophomore at Harvard College, laboring away on a small idea to bring the world together in a better way.
The first thing you may notice is that in this scenario there aren’t many numbers that we can give like we would usually when utilizing a BOM. This is because at such an early stage it’s pure imagination. Later down the line it will be possible to revise this model when more information has come out through market research and success metrics can be established. I don’t think you’ll see this scribbled with glass marker on a window any time soon, but it is a useful exercise for someone planning on developing a product on their own or with limited resources/skills.
After you have a rough sketch of the high-level features from creating your product development BOM you can start exploring the features you want to explore in your product concept. The L1, L2, and L3 segmentation of features in the Feature Tree allows you to go as high level or low level as you are comfortable getting in the initial stage of product development. Typically, before this, you might want to explore an Affinity Diagram to get an even more rough idea of the ideas you want to develop.
Unlike the modified BOM that we utilized earlier, this is a straight-forward model used in the same way as it would on an enterprise business project. Going further on these features can be translated into process and system flows for consideration of deeper detail on functionality.
Wireframes
Since we’re tailoring this example a bit to web technologies, one good speculative model to do up front are wireframes. This is actually a pretty standard visual diagram used in product development, so I won’t go into too much detail about how it can help shape a product from the beginning. Typically wireframes on an enterprise requirements project wouldn’t come out in such an early, high-level stage, but remember that this is about forming the vision for your product.
Once the vision has been laid out for what you want your awesome new product to be you can expand on the idea further by creating Process Flows, Business Data Diagrams, and Ecosystem Maps to finish painting the landscape of your dream product. And, if you are so inclined, requirements can be written from these models to be passed off to developers, or to be used by yourself if you’re developing your own product. Requirements and visual models can be very flexible in how they provide value, but the value is apparent when all bases have been covered and your explanations on the product will make sense to those who may join the project.
