Nowadays, mastering your domain of expertise is insufficient, in order to become a true professional one has to expand his or her horizons to different domains. This is why there is a growing trend of designers learning product management, developers turning into fullstack developers and so on.
In this series of posts, I’ll introduce you, the product manager, to some of the keys for a successful mobile and web applications development, including tools and the developer’s point of view on the product domain.
Mastering Methodology
When implemented right, a development methodology can increase the team delivery rate significantly and make the development process manageable and transparent to others.
Today, the most popular methodology is the agile development, of course there are many more (like waterfall and spiral), but they are out of scope.
Agile methodology breaks the development process into short iterations that last from one to four weeks, usually called sprint.
Each sprint involves a cross-functional team which is able to plan, conduct requirements analysis, design, code and test. At the end of each iteration (sprint) a working product is demonstrated to stakeholders (like you!). Multiple iterations might be required to release a new version to the market, but the goal is to have an available release at the end of each sprint.
daily stand-up meetings, continuous integration, planning poker are just a few agile practices among others that will help the development team in reaching its goal.
One of the most important principals of the agile development is to measure the progress. After each sprint the team has to compare the predicted time frames with the actual frames in order to tune the predictions for the next sprint.
Here are a couple of tools to help you manage easily your agile team:
- Taiga — my favorite one, very easy to use and well designed
- Jira — the most known tool, very flexible but a bit complex to use
Lastly, feel free to tweak the methodology for your specific team’s needs. The methodology should not be a burden but help the team deliver high quality products fast.
Your Role In The Team — The Visionary Integrator
Simply said, your role in the team is to be a visionary integrator. Visionary is self explanatory, since everyone knows that the product manager should think about the craziest features and how to make the product more valuable to the user. But you might have asked yourself, what is exactly an integrator? Visioning the product is not enough, you have to make it come to life. You have to talk with the designers, so they can turn your vision into something beautifully designed and simple to use. You need to explain your ideas to the developers, so they can code them into an application. Be prepared to answer questions about the difficulty to code a specific design or any other question that may pop up by your team. You have to conduct this all operation, making sure everything goes according your plan.
Talk to your team, find what bothers them, what is holding them back and be ready to break any bottleneck, no matter what it takes. Learn to speak their language and be one of them so they feel comfortable around you. Demonstrate knowledge to gain their trust but don’t exaggerate. Just then you will become a true conductor.
Product Specification — Your Tool For Efficiency
As a product manager, the product specification is simply a detailed written vision of the product. As a developer, the product specification enables continuous development without asking the product manager about each and every screen and feature.
When writing product specifications, one must take into account the edge cases and cover all features and screens as full as possible, so the developer will have all the information he or she needs. In addition, navigating through the different screens and features must be simple, you don’t want to waste your developers’ time on trying to find the specification of the screen they are working on.
Lack of information and messy specs can lead to two possible outcomes:
- The developer will wait for the product manager’s answer which causes a delay in the development.
- The developer will use his imagination to fill in the gaps (though, sometimes it can be positive)
I found it best to write the specs in a document (Word, Google Docs, etc…) using a well known terminology for the whole team (both development and product). Sometimes words are not enough for the developer to fully understand the specs, embed the design when possible and add notes using arrows to locate them correctly. Think how to organize the specs before writing it. Usually it’s convenient to fully cover each screen and its components and then cover the generic functionality (e.g push notifications). Add table of contents with hyperlinks to easily navigate through the specs.
Conclusion
In this part, I wanted to introduce some high level concepts in development along with sharing my experience in the product domain. Later on, I’ll dive deeper into more technical concepts like how developers collaborate. I’ll also explain in detail some of the curses that you might have heard from developers, so stay tuned!