Lean for Software Developers

In one of the previous articles, I have touched on the subject of product development. We discussed the technical part of the product team — software engineers, and why it’s beneficial to have them engaged in the process.

It is commonly thought that it is Product Manager / Product Owner’s job to come up with ways to discover the product worth building. It is up to them to make decisions on which route to take to make the product successful — what to focus on, which features to include, etc.

Using the larger team’s perspective and skill set, however, can help them do their job better. There are a couple of tools that can be effectively used by software developers to bring more value and increase the chances of products being successful. That’s what we will focus on today.

We will consider how software engineers can help product teams not only deliver software, but also have an impact on the product’s strategy.

Most of these techniques are related to Lean Product Development — an approach to building products that is getting more and more popular in the tech world.

So what exactly is this Lean thing that we so often hear about, and how can it help us build better products?

What is Lean?

Lean Product Development is a set of principles and techniques that form a new way of thinking about building products, especially popular in the tech world.

You can learn more about the history and origin of the Lean movement here. Its value proposition is:

1. reducing long development cycle times,
2. reducing high costs of development,
3. focusing on providing value to the customer, and
4. eliminating waste.

There are lots of specific approaches and procedures that have been developed to help build better tech products, faster. If you want to learn more about these in the general context of building software products and businesses, “The Lean Startup” by Eric Ries and “The Lean Product Playbook” by Dan Olsen are perfect starting points.

Here, we will explore some of these methods — the ones that can be especially effective in hands of more technical people. Software developers who have them in their toolkits can become tremendously valuable team members.

Let’s jump right in!

Lean tools for Software Developers

Avoid writing code

When thinking about “eliminating waste” in the list above, we can consider different types of waste.

One of them is time spent writing code that is not going to be used.

We, software developers, love crafting beautiful solutions to challenging problems. As soon as the Product Owner comes up with a feature, we often immediately start thinking about the design and architecture of the code, tricky edge-cases, tests, and all that.

The thing is — all these gorgeous little functions, classes, and tests are meaningless if the feature is not useful in the first place. They become waste and overhead for future maintenance and development.

I argue that we should resist the urge to craft code just for the sake of it.

There are a couple of strategies to help us avoid writing code.

One of them is using off-the-shelf solutions. For example, why implement your own authentication logic, if you can use Auth0? There are multiple SaaS products that take care of problems commonly found in applications. More often than not, they are well worth the price — especially if you’re only in the prototyping phase.

Another approach is to investigate if it’s possible to achieve 80% of the result with 20% of the effort (The Pareto Principle). Maybe there’s a module already in the codebase that doesn’t fit perfectly, but with minor changes would do the job for the most part? If that’s the case, you should go ahead and propose that solution to the Product Manager. In some cases, they will be happy to cut corners to accelerate delivery.

Please note that this all applies more to products that are in the discovery phase than to systems with thousands of users. Once you’re done prototyping, the idea is validated and you need to scale it — by all means, do refactor your code and make it bulletproof and maintainable.

Push back on “gut feeling” ideas

When it comes to useless features, there’s something we can do even before getting our hands dirty with code.

As soon as the Product Owner comes up with a plan for a new feature, we should discuss the “why?” behind this idea. We want the PO to convince us that the idea is worth building — especially if it’s presented in a form of a fully fleshed-out spec of something that looks like months of work.

Be cautious — and ask questions like:

• Why do you think the need/problem we’re trying to address here exists in the first place?
• Why do we want to address this need?
• Why is this a good time to do this?
• Why do we want to go with this solution to solve this problem?
• What are the underlying hypotheses that we would be testing here?

A great Product Owner will have thought about all that beforehand, but it’s always better (for the success of the product) to make sure we tick all the boxes. Worse comes to worst, we will spend a couple minutes on that — and learn something about the problem and get more business context in the process.

Ideally, we’d have the Product Owner talk to engineers in ideas’ early stages. We want to start the discussion by focusing on problems and hypotheses, and not specific solutions.

Discourage long product backlog

The natural tendency of product backlogs is to grow indefinitely. We use them to prioritize upcoming work, but also to store our precious ideas that haven’t yet found their way to our immediate roadmap.

There is nothing wrong with it per se, as long as we’re not actually insisting on sticking to the plan too far in the future. If we, as a product team, do our job properly, we continuously react to the feedback we get from users. This means we change course often and a big part of these features/stories will be irrelevant once we eventually get to them.

That’s why we shouldn’t insist on having a project fully defined from the get-go. On the contrary — we should work with the Product Manager to come up with a minimum viable version of the functionality (I like the RAT approach here), implement it, listen to the feedback we get from users, and take it from there.

There is one caveat here — a caveat especially apparent to the technical members of the team. Having the scope and the vision constantly change means it’s harder to come up with a proper architecture of the system. This results in a need to refactor and rewrite functionality often.

Of course, it’s easier to think about the design of applications upfront, but it’s not reason enough to change the way we work on products. We need to adapt, and there are ways to productively think about systems’ design in lean processes.

Embrace change

If we want to build successful products, we should be fast and agile, and deliver value into the hands of our users as quickly as possible. It means we should release new versions of our systems often.

One thing that can become a bottleneck in delivering new iterations of the product is the deployment process itself.

If we want to avoid this bottleneck, two things help tremendously:

1. confidence that new changes won’t break the system, and
2. an automated deployment process.

Automated tests, pair programming, code reviews, etc. help with the first one, while approaches like Continuous Integration and Continuous Deployment take care of the second one.

I used to believe that setting up the CI process early into the project is waste. Thanks to my colleagues (kudos to @michal_knapik!) I have recently changed my mind.

If we want to release a new version of the app a couple times a week (and we should want that), having an automated process in place helps a ton.

It’s hard to gauge when exactly it is worth introducing a CI process. Prototyping phase is probably too early — you don’t even know if the project will exist in a few weeks. However, once you start getting people (even pilot users) to use it regularly and provide feedback, it’s definitely high time you put the process in place.

Help with analysis

There are hundreds of techniques that can help the Product Manager get insight into how the product is being used.

A great Product Manager will know how to conduct qualitative testing, user interviews, etc.

Software engineers can, however, be more efficient when it comes to quantitative testing practices.

One of them is running A/B tests. There are multiple SaaS products that offer these capabilities. Chances are, software developers will have an easier time working with them. Also, most of these tools focus on design, copy, and layout changes. Sometimes, if we want to A/B test more complex parts of the application logic, some implementation changes may be necessary. That’s where we can help.

The other thing that the more technical team members may feel comfortable with is analytics tools. Finding your way around cohort analyses and tracking usage on different operating systems and browsers might require some technical background. If playing with data is interesting for you, there may be ways you can help the Product Manager out here.

Engage with users

All of the approaches and techniques we’ve discussed so far are more productive if we have a good intuition on who our customers are and what problems they have.

Building this intuition and understanding customers are one of the Product Owner’s main responsibilities.

It is helpful if everyone on the team is also well-informed in this space. The closer the whole team is to users, the more productive our conversations are.

That’s why software engineers should strive to engage with users and try to understand their pain points. We can do it by:

• asking the rest of the team to include a broader, user-centered context when discussing upcoming work,
• reading conversations with users in our Customer Messaging Platform,
• or even asking to be invited to Customer Interviews to be able to meet users in person.

Using the words of Marty Cagan, a product guru and author of an excellent book “INSPIRED: How to Create Tech Products Customers Love”:

If you’re just using your engineers to code, you’re only getting about half their value.

– Marty Cagan, “INSPIRED: How to Create Tech Products Customers Love”

To dive deeper into this subject, I recommend this post by Teresa Torres.

Summary

If we want to be more effective software engineers and more valuable team members, we need to engage in the product development process more. If we want to (help) build better products, faster, we can use Lean techniques as our tools.

Lean focuses on three components of product development: Building, Measuring, and Learning — and going through these phases as quickly as possible. We have now learned a couple of tools that we can use and help our product teams be more effective in all these phases.

There is so much more to building great products than we have discussed here. I have only scratched a surface of things that can be effectively used by the tech-savvy members of the team.

If you want to learn more, I recommend you check out the books I’ve referenced along the way:

• “The Lean Startup” by Eric Ries,
• “The Lean Product Playbook” by Dan Olsen, and
• “INSPIRED: How to Create Tech Products Customers Love” by Marty Cagan.

I’m happy to hear your thoughts and ideas on other tools that we could use to help build tech products. Thank you, and see you in the next one!

Lean for Software Developers was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.