Engineering a Product Feature

Praveen Bathala is a former Tech Lead for the Product Organization at Abnormal. He has experience designing high performance, large scale distributed systems for over a decade. Prior to Abnormal, Praveen worked as a Lead engineer in the Cybersecurity domain. When he's not working, Praveen enjoys spending time with his daughter, designing 3D models for 3D printing, pottery, carpentry and spends time snowboarding in winters.

Praveen Bathala: Hello, everyone. Welcome to this lesson on Engineering a New Product Feature as part of the fundamentals of Product Development class. My name is Praveen Bathala, I'm a Staff Software Engineer in Product Engineering here at Abnormal Security and I'll be your teacher for this lesson. Before we get into our lesson, let's quickly recap the previous lesson in our class Product Design by Lilly.

What we learned from that lesson is design is a collaborative process across Product Management and Engineering. Much like the Product Management class before that. Solving the right problem or solving a problem the right way is insufficient. It needs to be solving the right problem, the right way. Design is an iterative process. It's never a one and done task. Testing early on with stakeholders, customers, gives valuable feedback and improves the design. Ensuring the outcomes match expectations is important. 

In this lesson, Engineering a Product Feature, we will learn the process I follow when building a product feature. At high level, agenda of this lesson is understanding the problem, discovery, and realignment, planning and execution, testing, and dogfooding, delivery and operations. We will deep dive into each of these steps. Before that, you might have seen this image in previous lessons in this class. We will focus on the Engineering part of the process for this lesson, which is highlighted here. As we might have noticed, product design and engineering are never one team finishing the job and handing off to the other, but collaborative processes across all of them.

Engineering is involved end to end in this cycle at different stages, with different levels of involvement. What does engineering process look like in product feature development? Engineering is a vital piece that's also product feature development puzzle. In this process, collaboration with product and design early on and often is key to delivering the world class product.

There is no one way to do this. It depends on multiple factors like size of the company, stage of the company, size of the project, short term value and long term goals, and so on. The process can change based on all of these factors. In this lesson, we'll go over a process in general and not specific to any factors mentioned earlier. This can be adopted in more situations.

First step, and also the important step to move in the right direction, is understanding the problem. So understand the problem the product team is trying to solve and why we need to solve this problem. Collaboration is key to understand inception of the problem and proposed solution by Product and Design teams.

More often than not early on in the process requirements and deliverables are a bit ambiguous and not all engineering questions will have a straightforward answer. Don't let that deter you from being involved in the process early on; solutions proposed early on in the process might not be feasible from Engineering perspective. So understanding the problem helps to contribute to the solution. Second step of this process is discovery and realignment. We'll first talk about the discovery and what it means. Doing the due diligence, spend the time to research or discuss with the domain experts on feasibility of the project itself.

Let's take an example of cooking a dish. So it's easy to follow the process. So this step is to understand if we can cook this recipe. Do we have all the ingredients and the tools to make this happen? And figuring out the current state of the world. Understand what things exist today, what technologies we have, how we use them, so we can make better decisions. From the cooking analogy this is figuring out what ingredients we have and if we don't have a specific ingredient, can we replace them with something else? implementing a proof of concept to disambiguate the problem. Some things must be implemented to surely know it can be done. The proof of concept itself can be an hour of work or a week, or sometimes longer, depending on scope of the problem and the solution.From our cooking analogy, this is to test if a specific part of the dish can be made as expected or not so we can proceed accordingly. 

Understand the team's capabilities. You can't build an enterprise search engine with a couple of interns. Same way, make sure you have the right talent required on the team to do this project. Irrespective of the total project feature set that should be built, always have a MVP feature set created. This will help with separating out what must be absolutely implemented and can or can be pushed out if needed. 

Next part of this discovery process is realignment with stakeholders. Discovery process provides valuable feedback and helps with assumptions made at the project inception. Share these findings of discovery process with Product and Design teams. Things that needs realignment depends on the findings from the discovery.

Few of them that help are, viability of the project scope and timeline alignment, communicating the known unknowns, short term visits, long term product vision. Skipping this step in the process can leave stakeholders with the wrong expectations of the product. 

Next step of the process is planning and execution based on all the learnings and findings from the previous steps, like understanding the problem and the discovery. We'll talk about planning first, although we are talking about just planning this step sets the stage for execution. Unplanned project will struggle executing efficiently. Based on the discovery, have a clear design and document it. One of the important parts of developing a product feature is documenting the design discovery, learnings, and expectations of the product. From our cooking analogy, this is the step of writing down the recipe so everybody knows how it's done and what steps are followed. Clearly break down overall project into tasks, keep these high level until assigning to the owner. From our cooking analogy this part is the same as coming up with the steps we need to do to make the dish. Define clear milestones that constitute the bigger deliverable at hand. Large projects should not be all or nothing style of delivery. Milestones help with this and provides opportunities to course correct, if needed, at different stages of the project implementation. Some parts of the project can still be unknown at this stage. Make sure they're accounted for in overall plan. There should always be a plan for operations and maintenance of the project. This should not be an afterthought and must be planned for and communicated to the stakeholders about ongoing cost of managing a project.

Now let's deep dive into the execution itself. Although it might seem like the only part that matters, but all the steps before this is what sets us up for a successful execution. Executing a plan is different from efficiently executing a plan. A plan is just a blueprint of the project. It can be executed in many ways. Going back to our cooking analogy, we could have planned steps to make a dish, but as you execute, you can do them in any order, but not all of them would get you a tasty dish. Task breakdown is important, but assigning them to the right person capable of executing it properly is more important. From our cooking analogy, we won't ask a new chef to cook a difficult part of the dish. Parallelizing some parts of the plan helps with the independent execution and creates a strong contracts between different parts of the system. For example, define APIs and their models. So different parts of the system can be implemented in paddle based on the API contracts. This also helps on block test development based on the API contracts defined. From our cooking analogy, this is where we can decide to cook different parts of the dish at the same time, to be able to serve them together at the end. First cut off, implementation of any task should be its correctness. Functionally incorrect task leads to bigger problems when put together with the rest of the system. This follows up on the previous statement of correct functionality. First, do not prematurely optimize without strong evidence of inefficiency. As we execute on the plan developed, keep stakeholders informed is important. Developing the product features that are high maintenance is a failed product. As they not only take valuable Engineering time to maintain, also hinders the team's ability to deliver on other projects.

All product features must have as much visibility into under the hood operational metrics as possible. There's no such thing as over instrumentation. Metrics and logs quickly give away the problems in the product after all, you cannot fix something you cannot see. Having a functional test suite is important to verify the functionality of the implementation, but also helps with the regression testing as more features are added to the same product. 

Testing and dogfooding. Internal stakeholders are the best testers as they understand the project from requirements to expectations and can quickly help find issues and solve problems. Provide new features to customers as early access to gather feedback before release. We talked about instrumentation during the execution step, but instrumentation without proper action is like a tree falling in a forest.Make sure key metrics are instrumented for and alerted on are actionable. For every product must have clearly documented requirements and expectations so internal and external users are clear on what the product is and what it does. 

Last step of our process is delivery and operations. Always GA in a controlled fashion, slow and steady. Communicate the status of GA to customers and stakeholders. Monitor the product operations and ensure the stability of the product. Focus on next steps of the product until you reach the not start of the product. 

This concludes our lesson. Let's quickly recap what we learned in this lesson. Engineering a feature is a collaborative process across Product andDesign product design and engineering are working towards the same goal.

Understand the problem and contribute to the solution.Better planning always yields in better execution and better product. Observability into the product operations is as important as a product itself. High maintenance product is a failed product. 

Let's quickly recap the class we have. In the lesson one, you learned how to Identify a Customer Problem. Lesson two, Designing a Feature that Solves a User's Problems. And in this lesson, Engineering a Product Feature. This concludes our lesson. Thank you for attending this lesson on Product Feature Development here at Abnormal Business School. I hope you are able to learn something new today and wish you all have a good rest of your day.

Thank you.