4 ‘Don’t be Stupid’ tips for Aspiring Product Engineers.
In my current role, I end up managing both a Data Analytics Applications Development organization, and also running a SaaS Product Engineering organization. Till recently, I used to struggle to understand what makes successful product engineers different from equally talented full stack engineers who work on custom app development.
Before jumping into the details, i thought it would be helpful to set the context right (imho) on a couple of key differences in a ‘Application Development Services’ and a ‘SaaS Product’ organisation.
1st and foremost, in a Services Engagement, the Customer pays all your engineering bills based on the effort that you put in and how you successfully justify it. Naturally there is an inherent bias towards building in more phases, time and effort while estimating to compensate for any risk, albeit with good intentions, since the customer will pay for it as long as it is reasonably elucidated. In a SaaS Product Engineering organization, all costs are paid by your own company, since the customer only pays a fixed ‘licensing’ fee. So it is in your best interest to design your process in a highly efficient manner (i.e ruthlessly prioritized features, heavily automated build process, and even building smaller use-n-throw code just to get something in front of customers to understand the value proposition from real world usage behavior as well as market traction before committing to fully scalable development builds.).
2nd, in a services organization, the engineer develops to spec. You don’t think too much about the end user needs since it is assumed to be built into the spec given by the BA/Client who unfortunately in most cases misses out on giving you the nuances of the end usage scenarios. If you build to signed-off spec, your responsibility is mostly done. Usage, or Issues arising because of lack of nuanced specs is typically the customer’s accountability. As a Product Engineer, if you build products without thinking through Usage, and relevancy of features, leading to poor customer adoption, rework or lack of market traction, it has got a direct bearing on your Product’s Success, its ROI, and eventually results in a blemish on your career. Hence, it is multiple times more critical to actively understand the product, the end customer who will use the product, their specific business pain points which your product is supposed to help alleviate, what’s the best way you can help solve it by designing the product features you are helping build. In short, you need to understand the end use of your product so that you can help it evolve to actually solve customer pain points, and hence drive better market traction and hence product success.
From this context, i have listed below some of the key ‘Don’t-be-Stupid’ guidelines to develop a really successful Product-Engineer mindset. There could be much better interpretations of the same depending on the context it is being applied to, as well as many more obvious ones which are missed out that are not there in the context which I operate from. Nevertheless this is a good starting point or a good scratchpad list :-).
1. Don’t Be Stupid — Understand how your code/product will help the end customer
No amount of caffeine can make up for the energy surge that you get from understanding how your code finally leads to making an end difference for a customer. Seek out, reach out, but definitely find out. You will be surprised at the Being-on-Cloud-9 feeling that you will get when your code helps solve a customer pain point or it ends up making your product win more customers. Actively Collaborate with Product Managers, Customers, Domain forums etc. to know more about the customer domain for your product. Become an expert of how your product will get used and use that understanding to design and develop like a kick-ass product engineer, or Be Stupid!
2. Don’t Be Stupid — Own the Quality of your Code
It’s not the Testing team, but the Coder who is responsible for the Quality of your code. Work with the BA/Product Manager/Owner to understand all boundary conditions, integration scenarios, use cases et al and Code to it. Work with your Product Owner/Tech Lead to understand all potential sideswipes that can derail your product and code quality, and hence customer perception and sales due to delayed releases , frustrating usage experiences or even worse, both. Every Bug, and not-thought-through scenarios identified in System/Integration Testing and even worse, in Prod just amps you up in the Stupid Product Engineer scale. Take Ownership of Code quality from all aspects, or Be Stupid!
3. Don’t Be Stupid — Understand how your code helps pay the bills and the pay hikes.
Actually every Product Engineer has a direct influence on the Product success and hence your company growth and thereby your growth. Understanding how your code (i.e. coded real-quick, minimal bugs, cost-effective deployment etc.) will help your product reach more customers and help support your company’s growth and hence of course the pay raise — all really makes it a win-win. Alternatively stay ignorant of the key factors where you can contribute to your product getting fast customer adoption and market traction in a profitable manner, and struggle for growth and the raise i.e In short, Be Stupid!
4. Don’t Be Stupid — Understand the Context behind every product feature ask. Never Assume.
Accepting Assumptions or rules or Asks without understanding the context in which it was made surprisingly is the mother of all $%#@-ups. It’s amazing how many people (and a whole load of smart people too at that) actually suck at understanding context and causality, and jump to the easiest generic conclusion. As a Product Engineer, for instance, Understand Context to help decide when to develop use-and-throw code when speedier deployment is required to help drive and understand customer usage faster, or When to build scalable code with automation in-built for a more scalable, predictable, Cost-&-Effort Efficient Release schedule. This is one of numerous instances when the Product Engineer has to take the extra effort to understand the Context, seek out the nuances, or be Stupid and pay for it dearly.
In short, a really good Product Engineer will (i) Understand the Functional/Customer Usage scenarios to help build better product (ii) Own Product Quality as a key accountability (iii) Understand how s/he can impact his company‘’s sustainable success(i.e profitable growth) by making customer-relevant features in the most cost-and-time efficient manner, and (iv) Take an extra effort to understand the Context and Nuances behind every Ask/Assumption/Feature to get it right the first time since there is no one else available to pay for the re-work.
As mentioned before, there could be many more like Collaborate extensively, own DevOps, ability to make the right tech-choices based on cost/fit/time/scalability et al as well as various other interpretations of the points mentioned above based on the context in your company. Please share and help understand and prioritize to give a better perspective.
With more and more services being Productized, it is a fantastic time to make the move from a generic Full-Stack Engineer to a more well-rounded ‘Product Engineer’. Hopefully some of the points above will help upcoming Product Engineers understand some of the mindset changes which is critical for a successful transition. Trust it helps!
