The Role Engineering Plays in the Product Lifecycle

Today, we will talk about the Product's lifecycle in the engineer's eyes.

More from Ivan: 7.5 IntelliJ IDEA Productivity Tips for Software Developers

Let's start with the definition, “What is the Product?"

Product

An item that serves as a solution to a specific customer problem.

Example
At BigCommerce, we are building an eCommerce platform. Our customers want to promote Products and write blog posts. The blog engine is a “Product.” Sometimes, Products might be made as separate Products or closely integrated ones.

Platform

System that performs execution: cloud services, physical servers, databases.

Related Article: Use of Kafka and Kafka Streams at BigCommerce

Example
At BigCommerce, we use Google Cloud Platform which helps us manage resources quickly.

Incident

Unpredictable (sometimes even critical) behavior of the platform.

Example
Imagine a situation where customers cannot publish a blog post due to database issues.

Now we can move on to the stages. What steps do we need to perform in order to build our “Product”? We have three stages here:

1. Ideation - What do we want to get?
2. Development - In what way and how to do it right?
3. Support - Any questions or feature requests? Engineers are ready to help.

All phases are equally important. I honestly give each of them 33.333% of the engineers' resources.

To create a good Product, we need to think about the future:

• How will things work for our customers that are not familiar with a new experience?
• How to manage the “Product” during the incident?
• How new features should be added to the currently working “Product”?

We will cover all phases in detail and figure out why engineers have to participate in all of them. Just like many guides, this one will give you some answers. However, you may find yourself asking new questions. This is great because it gives you a chance to think through solutions with your own knowledge and experience.

You may think that this is the work of the Product group: the Product Manager, Business Analytics team, and Product Designer.

Nope.

Engineers have to take a vital role in the ideation phase because engineers know the platform the best and can answer questions like…

• Is this feature even possible?
• Can we implement it in a reasonable amount of time?

The engineering group needs to find the right balance between Product requirements and platform abilities.

Here are the issues that may occur if engineers ignore the Ideation step:

1. The future of the platform may be unpredictable. Imagine that the Product Manager decided to build a Highload Super Complex Feature. For example, importing 100k Products in 10 seconds. This may cause a big problem not only for the engineers but also for the whole platform's stability.

Tip: Knowing platform limits, engineers can set reasonable objective   levels for our future features. Maybe we need to drop off some features   of the Product or add more resources to the platform, but this question   should be answered before the development step.  

2. Unknown shipping path. Everyone wants to build new and shiny features, but sometimes we miss the point of how to evolve our platform and migrate clients from the old feature to the new one.

The case: You use a Super Cool Programming Language called SCPL. SCPL v1 works fine for you. And now you found a new SCPL v2 which is awesome. But there is no tool to migrate your code from SCPL v1 to SCPL v2. Would you like to rewrite everything? Definitely not!

Tip: Think about the integration of the “Product” into the platform and clients’ ecosystem.

Okay, you predicted all possible risks during the ideation phase. The feature set seems reasonable and you know how to do it. Now the most fun part is about to take place.

Coding party.

As engineers, we like to write code, but also, there are some steps that we like less–tests and quality.

Tip: Figure out all possible expectations about the code.

Did we choose the right language? Will it be so "futuristic" in the next 5 years?

Do we know our weak parts? Maybe it is better to write simple code and then refactor, or do we have to build abstractions right away?

What is the right quality level for our "Product"? Do we need to have 100% coverage, or is 85% okay?

There are a lot of questions connected to this stage, and I bet you already know them. I want to draw your attention just to one.

How will your code evolve in the future?

Please pause reading, and spend a few minutes thinking about it. Don't worry.  I'll still be here when you're done.

I consider this the most important and hardest one. We have only unconfirmed beliefs about the future, and we need to use all our experience to answer this question.

From my point of view, our code should be maintainable. This means that it is easy to change. The number of statements in the class, number of parameters, cyclomatic complexity, etc. are all your friends here. Having the right bar can decrease our future problems with adding new features to the Product.

Now we are going to the most underrated stage: support.

Let’s split it into two parts:

• Customer support
• Code support (services, libraries, etc.)
• Documentation

Customer Support

You know the Product; you wrote the code, tests, and built a fabulous platform. But your customers are not so experienced, and they often ask questions and request new features.

Everyone wants to have good support. When you are calling your mobile company, you expect them to answer your questions. The same philosophy applies to your "Product." Partners and customers or even engineers from other teams may raise different questions.

Build an environment where the Product has a good support line.

This gives everyone involved a good sense of your team and the high-quality features that you are building.

I have a few rules that we use in the team, and the strategy seems good. Maybe you will find them helpful:

1. Don't leave incoming requests without an answer for too long. Use reminders and other things to remember requests.
2. If you know the right answer - write it right away. Don't ask for permission, and don’t wait for someone else's attention.
3. In case of lack of knowledge - tag the right people. Like "Hey Ivan, you recently did some work in this area. Maybe you can assist." Don't be afraid to get someone into the conversation.
4. If the request is too complicated and requires a lot of work - ask for the ticket. You can subscribe to the ticket and continue the conversation there. This will be easier for future communication. Sometimes we have duplicate requests. Instead of repeating the same words, we just provide a link to the "issue ticket" that you already have.
   

Build a support system that you would like to use.

Code Support

There might be a bug in production, and as an engineer, you need to quickly solve it. Do you have a process for this?

First of all, you need to build metrics. Just pretend to be a client of your platform and think about the wrong ways of using your Product. Maybe you need to collect the number of bad requests, CPU, and memory load, number of transactions, etc.

Figure out which logs you need for the future. Definitely, it will be hard to log everything, but from the other side, no logging is not an option. You have to find the right balance.

There is a cool rule to figure out if you need the metric or not:

In case of any incident, will you get useful data from the metric?

If the answer is yes - then the metric is good. If no - drop it.

The perfect scenario for building code support:

1. Build valuable metrics that can trigger the system to start an incident.
2. Make a schedule rotation of your teammates. Put only engineers who are familiar with the code and can implement rollback or a quick fix in challenging situations.
3. Test it. Make an incident intentionally, (a small one, do not put everything down 😉) and validate the whole process. This is important because you do not want to figure out that someone’s phone snoozed the alert, and the platform just went down without any notice.

Documentation

Mostly everyone is afraid of it because we have to write words and not if/else statements.

Documentation (docs) is the last stage of the correct usage of the Product.

We build validators, checkers, put guards in the code, but sometimes it is impossible to automate everything and we need to write docs.

The benefits are obvious:

• We do not need to repeat the same things over and over again. Just give a link to the documentation.
• New teammates often ask questions like, "Why this...?" You can explain a high-level overview of the architecture and some edge-cases in the documentation. This will save you a lot of time in the future.

Always think about documentation, and just update it with every new feature.

It is easy to write documentation iteratively. Step by step.

Don't wait until all stages are done and then spend months writing docs.

Engineering is a core part of the Product lifecycle. They participate in all phases.

Remember that engineers are people who solve problems not only by writing the code but also by building good processes inside the Engineering Department.

Think about the present and the future of the Product. Write maintainable code and polish it with a good sauce of documentation.

Useful Links

• What is a software product?
• Product development process: The 6 stages (with examples)
• 7 key stages of product development lifecycle