~ 10 min read

Product Engineering: How to become an Agent of Change

How and why software engineers can make the difference
Image credit: labs.openai.com

IntroductionSection titled Introduction

Has it been ages since the last meaningful feature has been shipped? Do you have raging customers, excited about the project - or are they already looking for competitors?

It is this setting which got us thinking on the topic we call as “product engineering”. In this massive post, we will not only analyse the problem, but also give hints for the solution based on our own real life experimentation.

A Common Pitfall: Upgrading useless thingsSection titled A Common Pitfall: Upgrading useless things

Plenty of companies stop innovating, while everybody is very busy.

This is the difference between a strategy vs plan: do we simply plan to extend and improve a codebase, or do we have a strategy for increasing the market fit?

A lot of teams plan for minor improvements of all the little things. While the revenue is coming in, that might be fine. For a project that brings in revenue it is worth investing in its quality.

Many companies that are outside of the initial startup phase struggle here. Amazon tries to combat this with slogans like “it’s always day one”. Though it is just a sentiment, just a slogan, it adresses an issue faced by many companies.

The more problems we solve for the user, the more the flow of money into the company can increase. Because in the end, it’s the developers who create that value.

Thought Experiment: Why are we called Software Engineers, not Product Engineers?Section titled Thought Experiment: Why are we called Software Engineers, not Product Engineers?

Software engineers play a crucial role in the development of modern technology and digital products. But…

What if we were called “Product Engineers” instead?

Why has the software industry chosen to label their professionals as “Software Engineers”? What implications has this on the role in the development process?

One key issue that arises is the distinction between “product ownership” and being a “coding monkey.” As the role of software engineers continues to evolve, it’s important that as professionals we have a clear understanding of the product we’re working on and how it fits into the larger picture of the company. The more knowledge we engineers have about the product, the better decisions we will make, and the better results this will yield for our company.

In maybe every company, engineers really do more than just executing the ticket plan. Features get challenged on feasibility and cost. Engineers often care more about data security and know about corner cases in the user workflow.

As engineers mature in a company they naturally turn into product engineers, while they might have started out just as a coder that was unfamiliar with the business.

Seasoned engineers often not only give valuable feedback to the PM, but also come up with entire product ideas and implementation plan on their own.

Some might argue that product management really is only the responsibility of product managers, but in reality, engineers often plan their own sprints and have a significant impact on the product roadmap. This highlights the importance of engineers becoming more involved in the product development process and taking on a more “product-focused” approach.

It seems important for onboarded software engineers to turn into product engineers. This shift in mindset can lead to better results for the company and a more fulfilling career for the engineer. By having a clear understanding of the product they’re developing and how it fits into the larger picture, software engineers can make more informed decisions and drive the development process forward in a more effective and impactful way.

Time To Market: Unit test, Integration Test, Market Test?Section titled Time To Market: Unit test, Integration Test, Market Test?

Test your hypothesis as early as possible

This was a personal learning that one founding CEO we both knew felt strongly about. A key learning which he often shared in company meetings. If we take this seriously and don’t disregard this as a general sentiment, this has meaningful impact on our day-to-day work.

This advice motivates the creation of small MVPs. If MVP creation takes ages, we are no longer in a position to follow this advice. Agile is supposed to help us here and it urges us to think in terms of incremental, 2 week releases, over big deadlines. Actual MVPs over 100% completion. In the reality, even agile planning often looks quite different.

Defining an MVP is a true struggle. It is easy to fall into the trap of getting lost in planning the first perfect version of the product, instead of following the strategy to test and roll-out products early.

Companies like N26 have been known to dish out minimal features, which were available for some time, but then disappeared again. This is almost unimaginable for most IT companies. Features take forever to be implemented in near perfection, and are almost never rolled back, since having wasted all that time is an impossibility for the responsible product owners.

Expensive features often turn from experiments to a huge gamble to a long-lasting commitments. In most cases these products then go into maintenance mode, and people get eager to plan to extend these again with minor advancements. Now you have a team of business people and engineers talking and planning about a product, which is actually not bringing you anywhere.

Features that become too big turn from experiments into large scale gambles, and are likely to turn into dead maintenance products.

Our recommendation is to give experiments 3 weeks for the market test. Anything after that is likely to become too big to fail, and will never be rolled back.

The best way to learn is to get product feedback as early as possible, be it direct or indirect feedback.

Feature Experiment Evaluation: After shipping a feature, we are looking into data to know if the feature serves its intended purpose. In the end the customer decides:

  • Customers give us written feedback on the feature
  • Customers are using the feature
  • Bookings / Sales increase
  • Other more fine-grained data
    • Has the usage time decreased, as the app got easier to use?

The way outSection titled The way out

Given the what and the why - how do we move out from here? How can one turn into a product engineer and help the organization as a whole?

TimeSection titled Time

Understanding the product takes time. Don’t be that over-motivated new joiner that wants to change everything during the probation time. It’s not going to work, and it is more than likely that you’re going to work on the wrong things.

Take time to really understand the company and the product. After 1-2 years in a grown startup you should have seen and understood enough to come up with reasonable solutions.

Failure, your best friendSection titled Failure, your best friend

Your biggest priority as a product engineers is to create MVPs. In the true spirit of agile, producing -something- at the end of each sprint, that’s where you come in.

Your first MVP is going to be bad though. Pretty much no question around that. Creating MVPs is something that needs practice. Similar to how the first pancake always sucks, we found that across companies, when a team first does a MVP, it usually sucks at it. But this is your starting point, and where you and your team can learn valuable lessons.

Intrinsic MotivationSection titled Intrinsic Motivation

Being productive and creative as a software engineer is crucial and motivation plays a big role in this.

Here are some ways companies can keep their engineers motivated:

  • Giving credit where it’s due for a job well done
  • Providing growth opportunities and room for career progression
  • Creating a positive and uplifting workplace atmosphere
  • Offering exciting and demanding projects to work on
  • Making sure each engineer feels like they’re making a difference in the company and its products

Staying up-to-date with the latest tech and improving your skills is important for software engineers.

Companies can support their engineers by offering:

  • Hands-on technical workshops and training sessions
  • Attending conferences and events
  • Access to online courses and certifications
  • Internal training programs and development opportunities
  • Mentor-ship and coaching programs

It’s not just about tech though, soft-skills training like networking, teamwork, and communication are also important. This helps improve the engineers’ overall performance and teamwork abilities.

By offering motivation and training, companies can build a work environment that drives productivity, creativity, and employee happiness.

Innovation TimeSection titled Innovation Time

Innovation time: Moonshots! Break out of the sprint!

Without wiggle room and innovation time, there is no way to make change happen from the bottom up. So to implement change while everybody is working an incremental, sleepy plan that leads nowhere, you may need to set some time aside to work on new ideas yourself.

This can be called as innovation time and is sometimes even an official process in engineering companies.

What can be done when there is no such time and there is no wiggle room to get anything done outside of the daily work? Well first you would be surprised what you can get done in little amount of time with the right tools and intrinsic motivation. When there is really a product manager that is breathing down your neck it might be actually time to leave. But in many other situations,

You sometimes get wiggle room, by making wiggle room.

This might be a very bold move depending on the company and situation. In reality when you actually make stuff work, people will soon forget about the actual ticket you were supposed to implement. But for the situation where this is not the case, maybe this take on innovation from Elon can give you a new perspective.

How to get your MVP out the door?Section titled How to get your MVP out the door?

Companies must continually innovate and adapt to stay competitive in the fast-paced world of technology. Nonetheless, introducing new and untested features might be a daunting task when faced with slow development. In these circumstances, it’s critical to balance risk and reward and carefully weigh the possible advantages of a new feature. Try to approach this challenge with a data-driven mindset, conducting thorough market research and user testing to inform their decisions. Companies should also place a high priority on agility and the capacity to make quick product revisions in response to customer input. Companies may manage the difficulties of releasing new features and continue to foster growth and success by keeping these methods in mind.

Conclusion: Why Product Engineering and MVPs Are Critical for Successful Product DevelopmentSection titled Conclusion: Why Product Engineering and MVPs Are Critical for Successful Product Development

It’s crucial to understand the product you’re working on and how it fits into the bigger picture of the company in the field of product engineering. Engineers should challenge features on cost and feasibility, care more about data security, and be aware of corner cases in user workflow in addition to just carrying out the ticket plan. When engineers advance in a company, they naturally transition into product engineers, frequently providing the product manager with insightful feedback as well as developing and implementing full solutions on their own.

Making small MVPs is one method to change the engineering mindset to one that is more product-focused. Although defining an MVP can be difficult, it’s important to design the initial iteration of the product and stick to a testing and early product release strategy. Businesses like N26 have a reputation for providing basic features that are available for a while before disappearing once more. For the majority of IT businesses, who take long to implement things in close to perfect condition and never roll them back, this is practically unimaginable.

Our recommendation is to give experiments 3 weeks for time to market. Anything beyond that is likely to become too big to fail and will never be rolled back. The best way to learn is to get product feedback as early as possible, be it direct or indirect feedback. By following this approach and adopting a product-focused mindset, engineers can make more informed decisions, drive the development process forward in an effective and impactful way, and create an MVP that delivers the most value for the users.

Share:

Any Comments? Join the Discussion on Twitter: