~ 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

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 researching 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 and from our own real life experimentation.

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: Is the task just a plan to extend and improve a codebase, or is it part of a strategy to increase the market fit?

A lot of teams plan for minor improvements, for reworks of, this, this, that and the other. 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, the idea is needed for 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?

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 development 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 they have a clear understanding of the product they’re working on and how it fits into the larger picture of the company. The more knowledge engineers have about the product, the better decisions they will make, which will yield better results for the 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 (PMs), 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?

CEO: Test your hypothesis as early as possible

This was a personal learning that one of our founding CEOs felt strongly about and 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 MVPs take 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 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. Really, we are just planning(!) the first version of the product, but not 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 time to market. 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 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?

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 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 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 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?

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 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: