This week I read an interesting article about “Product Engineering”. I’ve often found myself as both a product leader but also the engineering lead, and absolutely feel like I couldn’t do one without the other.
Engineering and Product - Yin and Yang
For most of my entire academic training and even professional career I have always been an engineer, I have an undergrad in Software engineering, have coded most of my life and always made sure I kept up with latest technologies. However when I started my own company, I felt like something was missing, understanding our users, how they thought, their pain and needs, was something we needed and didn’t have.
So I started focusing on growing my product brain, and shifting how I as an engineer thought about things (very detailed and with all the going deep into lines of code and what techologies to use) to a higher level vision, where I thought about roadmaps, how the different feedback I was hearing from customers translated into features and how they all connected with each other.
While doing this shift, I found myself using 2 skills from my life: Gaming and Reverse Engineering.
As I looked at a product and features, I immediately formed in my head the product tech tree.
If you’ve ever played Civilization, you will recognize the following image:
I’ve since used this same method to think about products and features that I want my teams to develop. Some typical questions I ask myself is:
What dependencies do I need to deliver a feature or product?
Can I generate revenue from those smaller dependencies? (meaning that I don’t have to wait for the final feature to be developed to have it make generate revenue.)
However my version of the tech tree, also creates a central trunk, you can think of this as the features or products that fall within the core of your business. As features mature and time passes the central trunk expands, allowing you to also expand into other areas, lets take a look at an example.
When I initially built BinaryEdge, I knew I wanted to get the product to a point where organizations didn’t have to search our raw data, the reality is that without having technical staff that understands scanning data it is hard for organisations to use the raw data, in my head they could just type their company name and from there the system would find the domains, sub-domains and ip addresses (these types of products are now known as Attack Surface Management platforms).
Our core branch is represented in green here.
Ok now that I had a platform where I could type the name of an organization and the system would generate a security report and monitor the assets of that organization, 2 other branches unlocked for us as a business. We can also see our main branch expanding (our core business).
Now we need to figure out time and features needed for expansion into these new branches, and this is where reverse engineering comes in, because u need to figure out these needs, months if not years before the need appears (as there is also a need on the business side to investigate if the market and return is worth it). Reverse engineering is the process of observing how something works and starting to drill into how it works or how it was built. This process typically involves investigation, a lot of reading and talking to customers.
These diagrams are the very high level version of how the real version looks like. I usually have 1 or 2 pages worth of notes per feature, on why we should do it, other competitors that do it well, or potential revenue they might generate.
The reverse engineering part becomes specially useful as we think about moon shots. These are projects that are far/further out from your core branch and in the future. Imagine starting at the “Raw internet scanning” square and in the opposite corner having “cyberinsurance” and having to write how to get from point A to point B.
Because I have the engineering background I can also drill into the technicalities of how much work and what type of work would be needed for these features to be delivered and how they connect with each other to deliver a final product planned/thought experience.
Now, I can hear you snickering in the background if you’re a product manager “this is easy planning”, my answer to you would be “Ok, lets see you correctly plan the order, technical needs and timining needed to get these features built”. If you’re an engineer you’re saying “Well, this is basic planning, I can easily write the spec the API or plan the data schema” to that I answer “Sure and I bet you’ll end up with a feature that your customer neither needs or wants”.
The concept of product engineering led me to write this as I always knew the skills I had, but never a way to name them. Now I do.