I have wanted to be involved in Product Development since I can remember. Whether constructing cool medical devices, building innovative software tools, or inventing tasty drinks, my focus for the last 20 years was always on creating things that could somehow assist or bring joy to others.
During these different experiences, I found that product development methodologies depend on the industry. E.g., food R&D still follows a basic waterfall structure accessorized by dozens of norms and international quality standards. I have also witnessed the huge evolution within the same vertical market. In the early 2000s, software development companies followed lean thinking focused on prototyping, and 20 years later, most use an Agile approach.
But how did all these industry transitions become smooth with so much different thinking involved? Regardless of the tools (or magic) that we use to define and develop a product, the road to success is always paved by the same basic principles, which I affectionately call the "I's in Product Development."
“The I’s of Product Development”
Product thinking never even begins without an Idea. Some concepts are born within a stakeholder’s dream, others arise from an urgent market necessity or a team brainstorming session but the starting point is always a figment of someone’s imagination.
The key to leveraging any idea from an abstraction into something tangible is communication: new concepts subliminally harbor a request for change and need to overcome a human’s basic instinct to “stay put”. The idea not only must be groundbreaking in its field but, most importantly, it has to be specific and actionable.
To gain your audience’s approval, it is key to make a clean visual presentation pushing your idea forward and prepare solid answers to the most basic questions such as:
- What does it solve?
- Where does the market stand?
- What are the main challenges, and how do you propose to solve them?
The next phase is Inception — picking up theoretical material and getting all wheels into motion.
It is where the "how" may begin to diverge. Still, no matter the preferred methodology or company's ISO or HIPPA regulations, you must always organize the team to include the client (or stakeholder), product management, and technical staff and describe the overall process's ground rules. And this process should be the one that works best for the people involved at this stage.
It is also essential to transparently define the extent of each role’s contribution and ensure all involved parties are aligned with the strategy. Creating this trust matrix early on may prevent disruptive interventions or the creation of parallel communication channels that jeopardize healthy product development.
After the team and process’ definition, the original concept must be put up to the challenge, and the Insight phase is often the last one of a great idea.
The team begins to work collaboratively: deconstructing the goal, analyzing essential features, understanding possible workflows, and describing cause-effect relationships.
It can either lead the team nowhere given the lack of alignment with previous expectations (e.g., costs, technical viability, or time to market), ending the product prematurely or sending it back to the ideation phase, or into the foundations of the next 2 phases.
Iteration and Implementation usually happen simultaneously, and it is of most importance to harmoniously balance these two as they tend to create friction between the team.
This is why creating synergy between management and technical teams instead of promoting niched events is important. An aligned product team will work quicker and more effectively if you create development cycles that:
- Promote regular presentations;
- Have specific time boxes for constructive dialogue (with both internal and external teams);
- Have space for retro and prospective evaluation, helping to emphasize the focus on the result and not on the delivery.
Finally comes the Impression phase, with everyone just hanging on, barely breathing, waiting for the results of their work.
Good feedback brings great satisfaction to the team and sends a clear sign that we are walking the right path, but receiving a clashing judgment can affect our capability to bounce back.
It is pivotal to recognize if the criticism was perceived as a defeat or a challenge and, in any case, act upon it immediately by listening to the team, revisiting the requirements, and sometimes even changing the process's paradigms. By establishing this culture of transparency and openness, you will keep the product's integrity while making the most out of everyone's potential.
Summary
Product Development is not a dogmatic process, and teams are not unidimensional. Being true to one of the many methodologies helps Product people stay tuned in on their main aim — to deliver the best product. However, we must see beyond a designated plan and adapt to every circumstance as long as we understand there will always be some unsurpassable steps.
So it doesn't matter if you dot all I’s and cross all T’s; what is important is how naturally you change the story and rewrite your product ideas, as long as you always get to the end of the yellow brick road.
