Why Product Driven Development (PDD) is Essential for Startups
Choosing the correct software development methodology for your team can be a tricky task with different styles providing pros and cons for various technical and business requirements. It is easy to get overwhelmed by all of the trendy buzzwords and to find clarity regarding how your team should develop timely and quality code.
However, what if I were to tell you that there is more to the software development life cycle than debating Scrum vs Kanban vs Waterfall? What if there was a way to reframe developers’ perspective of their work beyond mere technical implementation?
I am here to introduce the concept of Product Driven Development (PDD). What is PDD? PDD is NOT a new software development methodology. Instead, It can be observed as an emergent behavior in companies which allow their engineers to participate in product ideation through cross team collaboration.
Wait, hold on a second, that’s a lot of words. Let’s formulate a better understanding of what PDD is by unpacking what product driven development looks like at Policygenius.
In order to transition from ideation to final product, Policygenius product managers and designers use a goal setting framework called Objectives & Key Results (OKRs). This process outlines an Objective (a company goal) and a Key Result (quantifiable measurement to track the goal) to organize and evaluate action plans. When the product teams brainstorm new objectives they use customer feedback and quantitative data to drive decision making.
While OKRs sound like they fall strictly within the product teams domain, they actually require continuous attention from the engineering department to succeed. In these joint meetings engineers analyze the feasibility of product objectives and present risks, unknowns and potential setbacks down the road. This technical feedback helps to accurately derive the key results that will be used as milestones to track the success of the objectives.
While close interaction between engineering and product teams is clearly beneficial for the organisation, it is also important to ask what the individual has to gain from a product driven culture. Personally, when I participate in OKRs and other product meetings I develop a holistic understanding of my work. The ability to trace the line of reasoning from ticket creation all the way to customer feedback is crucial because it provides answers to “why” my software changes are important. With this exposure to a product oriented culture, even seemingly arbitrary CSS tweaks feel important and rewarding because I understand the overarching thought process behind the change.
Before my exposure to product driven development at Policygenius, I was never given the opportunity to take part in product planning. While working for my previous employer I was not invited to attend product meetings because junior developers’ input was not considered very important. After these meetings engineers would receive a summary of business objectives with little visibility into why specific product decisions were made.
Due to this isolation, I felt siloed in my role as a backend software developer, not understanding why my changes really mattered and who my changes were impacting. I never once met a customer and felt stuck in a role of technical implementer. Worst of all, I only had a vague idea of how the product was actually used and only knew enough about it in order to test my software changes.
Having worked at both a product driven organisation and a more traditionally bureaucratic one, I have seen how developing a product driven mindset has improved my skills as an engineer. The most important skill that I learned from PDD is understanding the value of product driven trade offs. If you are only responsible for technical decisions you may be biased towards over engineering and creating perfectly optimized code. You may also be more inclined to reinvent the wheel because writing your own framework or custom implementation can be fun and improve your skills as a software engineer. While these have good motivations they can often conflict with creating a reliable product in a timely fashion. Adding the dimension of product focus to your decision making will allow you to be more deliberate and circumspect in your approach to code changes.
Now let’s revisit that definition again:
Product driven development can be observed as an emergent behavior in companies which allow their engineers to participate in product ideation through cross team collaboration.
Ultimately it is in both the company and individuals’ best interest to foster product driven development. When analyzing your current position it is important to ask yourself “how connected am I to the product and the organisation at large”. If you can see any disconnects between you and product planning with cross discipline teams then you may be missing out on a richer development experience.
To find out more about life at Policygenius, read Policygenius Day-in-the-Life: Software Engineer
We’re Growing!
We’ve gathered a pretty great bunch of product, design and engineering folks to tackle some pretty tough problems in the insurance industry. Fun fact: we still need a lot more. If you’re interested in what we have going on here and want to help us on our mission to make insurance suck less, mosey on over to our careers page to see if something fits.
