Bridging Product Management And Development

As both a programmer and a writer, I have seen firsthand how differently logical and creative thinkers interact with the world. All of us use both creative and logical skills every day. Logically we know that there are certain steps that we must take in our daily life such as brushing our teeth and earning a living. We also know how to be creative whether we express it by singing a song or thinking of a name for a new pet. However, many of us that tend to prefer one style of thinking over the other fool ourselves into believing that we lack the ability to understand things that involve our non-dominant style. When it comes to certain types of logic such as mathematics or computer programming, a great number of the creative people shy away from trying to understand what goes on under the hood. Likewise, logical thinkers strive to comprehend the world through numbers and precisely defined steps exclusively and dismiss those things that they can not clearly define through logical means. In the software world, this is very unfortunate because the best programs are those that have a rich creative user interface for us humans, as well as a streamlined, precise, efficient logic structure for the computer.

If you take a peek inside a software company, you will often find that there are two distinct teams responsible for creating the software. On one hand you will find the product managers which are our creative thinkers. These are the folks responsible for designing the software so that it is meets the clients needs, is easy to use, and easy on the eyes. On the other hand you will find your software engineers, or computer programmers. This is your (typically nerdy) bunch that are responsible for taking the vision of the product managers and turning it in to a reality. These two groups view things very differently. If you want high satisfaction with your software, it is crucial that these two teams have a healthy respect for one another and know how to take a stroll in the other-half’s shoes.

So you may ask the question: How do we bridge the gap between these two very different worlds? For developers the best way to understand the product management side of the project is to be involved from the very beginning. By taking part in the discussions where the intended users’ requirements are defined and planned functionality is scoped out, the programmer will have a clear understanding of what this mess is really supposed to do? This is extremely useful because it allows your developers to understand the “why” of things. This gives them the added ability of catching simple specification errors that can cause complex problems if not caught until later.

For example, a product manager might accidentally document that the client wants 2 + 2 to equal 5. If the developer was not part of the conversation where the client said that they really want 2 + 2 to equal 4, they might think that the request is rather odd but still code the program as specified. However, if the developer was in the design meetings, he or she is likely to realize that the document simply has a small typo. You may think that the developer would at least ask for clarification on this issue regardless of whether or not they were in the design meetings, but you might be surprised. Remember that us nerdy types are often shy and will often go to great lengths to avoid actually interacting with another human. (I am kind of kidding here… but just “kind of.”).

That seems easy enough. But what do we do for our product managers to help them navigate across this bridge as well? From my experience, most PMs have no interest in learning how to code, so it seems silly for them to learn the ins and outs of programming. What they need is a high-level understanding of what a program really is and the key concepts a developer must consider when creating a program.

For example, as a driver, the PM doesn’t need to understand all of the specific parts of the engine nor how they fit together. They know that they need to be able to get into the car, turn the car on, drive to their destination, turn the car off, and get out of the car. Too many times this is as far as product management goes with the design. In order to really understand what they are designing, they need to at least be aware of some of the finer details. They may not need to understand how the engine uses the gasoline to get the car from point A to point B, but they better be aware of the fact that the car needs the gasoline. Otherwise, they may find themselves stranded a few miles down the road. They will be frustrated that the car did not do what it was supposed to do (get them to point B), and the developers are going to be annoyed that the product managers failed to make sure the car had fuel.

This is an example of how the two teams, if allowed to stay in their opposite corners of the ring, may end up extremely aggravated with one another and/or start playing the blame game. With a little communication and enlightenment, this situation can be avoided. The groups need to understand that they are the yen and the yang of the final product. Developers need to understand that without their PM counterparts it would be them on the phone with the clients. Likewise, product managers need to remember that without developers to give concrete form to their designs, they would simply be very stressed out visionaries without any way to bring their dreams to fruition.

One final note. If you happen to be in a company that is fortunate enough to have a quality assurance department, both teams can learn a great deal by spending time with these folks. Due to the very nature of their jobs, QA is required to understand how both sides of the coin operate. And, perhaps most importantly, how to effectively communicate with both product management and development. The ratings of the model for the development of the business can be checked at https://www.wavemaker.com/rapid-application-development-model/ site. The benefits should be made available both to the business person and to the clients.