Introduction
In previous parts of the “Consulting for Software Developers” series, we focused on earning the client’s trust and figuring out how to give them the best technical advice.
Now, we will discuss how we, Software Developers, can have an even greater impact on the product we’re building.
Previously, the subject we were concerned with was giving advice on “how should the feature be built?”. Now, we will switch our focus to a much broader, strategic questions like “should the feature be built?”.
If this sounds daunting, it’s because software developers’ job is traditionally regarded as technical and down-to-earth, rather than visionary work.
Actually, quite the opposite can be true! We will see how you can (and should!) think about the product on a much higher, strategic level.
We will discuss how we can develop a new mindset to:
- help our team ship the right product to our users,
- have more impact on the project,
- enjoy our jobs more, and
- become irreplaceable team members.
Before we jump in and see how we would go about that, let’s pause for a minute and ask ourselves…
Why should you care about the product?
In the first part, we’ve discussed why software developers might want to become more than code monkeys on their projects.
One of the ways to have more impact is to think more broadly about the product development process. There are multiple benefits of us engaging in this process on a higher level than writing code.
It is challenging
Photo by Mikito Tateisi on Unsplash
We, software developers, like intellectual challenges. We do encounter a lot of them in our day-to-day work: thinking about the code, designing the infrastructure, double-checking the security processes, etc.
It just so happens that some projects, or at least parts of them, are not that challenging.
The client may want us to build yet another CRUD app in Rails for them. Or maybe they need to have some documentation prepared. We’ve all been there, right?
Whatever it is, I’m sure you agree that some aspects of product development can get a bit mundane. We know that they are crucial, but still, we can’t quite enjoy them.
If you switch your mind to thinking about the product as a whole — a new world of challenges opens up. There are a lot of difficult problems to be solved there:
- “Why don’t our customers behave the way we thought they would?”,
- “What would our users find the most value in?”,
- “How do we figure out the optimal subscription fee?”, etc.
If you feel uncomfortable just thinking about these questions, that’s exactly how you should be feeling — these are inherently complex issues and big challenges.
Leaving all these challenges for the product owner/manager to solve can mean a lot of wasted brainpower of the team, and a lot of additional risk.
It is satisfying
Photo by Ali Yahya on Unsplash
Remember the feeling of crafting a beautiful piece of code and being proud of it for the next couple of hours? Or how you had this great infrastructure optimization idea that saved your company hundreds of dollars a month? How about that one time when you got great feedback on a code review from one of your senior colleagues?
Felt great, right? It sure did for me.
Now imagine the same feeling, but 10x stronger, when the experiment that you’ve devised and developed evolves to be the most-used feature in the product.
Looking at the product more broadly than just from the implementation point of view can get really satisfying. You will be way more proud when the product turns out successful, and users leave great feedback.
Being involved in product development gives us a chance to extend the creative process beyond code.
It is an investment in yourself
Photo by Sharon McCutcheon on Unsplash
We, software engineers, need to master multiple skills to do our job better. Some of them are domain-specific, technology-specific, some are related to software engineering principles in general.
Developing specific (narrow) skills feels more productive, and has an immediate return on investment in your current role.
Say you’ve encountered an obstacle in your day-to-day work and feel like you’re lacking some technical knowledge. It would be a great idea to go and educate yourself on that bit. It can instantly unlock you and make you more productive. You gain a more in-depth understanding of the intricacies of the technology you use. It will help you in the future.
Just not the future in which you use a different tech stack.
Working on the more generic/broad skill set is, on the other hand, more easily transferable to other projects.
One of the examples could be learning how to communicate with clients effectively. It’s something that may not be immediately useful, but it will prove invaluable down the path in your career. It won’t matter that your next project is built using a completely new technology — you will most likely still need to communicate with clients and/or stakeholders.
I think that Product Development skills are as generic as software development competencies go. All software is created to be used by someone, so all software products need to keep users in mind.
Focusing on the product, and not only on the technology, makes your skill set more universal.
It makes you a more valuable team member
Photo by Hermes Rivera on Unsplash
If you were a CEO, or a Product Owner who works with technical people on a daily basis, what kind of engineers would you like to have on your team?
Of course, they’d need to know the technology. They would have to be smart. Any technical challenge you throw at them — they should be able to solve as quickly as possible.
But wouldn’t it be great if they were more than that?
What I would want to see is people who are passionate about the product. People who care about the outcome. If they had great ideas, I would love them to speak up and help shape the product. If my ideas don’t make sense, I’d much rather have them raise objections early, than have to learn it the hard way.
One more thing to keep in mind is that for any technology X, there are multiple Senior X Developers “on the market”.
Senior X Developers who can help you think about and shape your product, on the other hand — they are not that easy to find.
Keep thinking about the product, the vision, and the strategy. If you do that and engage in the product development process, you become much more than a software developer. You become a real technology partner.
It can make the product more successful
Photo by Samuel Zeller on Unsplash
This probably goes without saying. If you’re trying to have a successful product, having a team that’s fully dedicated to making it so will mean the world.
Sure, it’s usually not up to software developers to decide on the vision of the product. There may be cases where the decision maker is a visionary and having multiple people think about and discuss plans will only mean more noise.
Most of the time, however, the more engaged the team is in the process — the bigger the energy and motivation.
Sometimes all it takes for the product team to become successful is a brilliant idea — it would be a shame if you (or someone else) had one and didn’t speak up.
And if the product turns out successful, well, it’s great for your personal goals too — think new experiences, a more impressive portfolio, etc.
But… there may be implications
Photo by Hubert Mousseigne on Unsplash
As soon as you start focusing more on the product as a whole and engage in the product development process, you may begin to see some changes in your attitude. There may be implications.
In some cases, instead of listening to the requirements and trying to make your part (code) perfect, you may actually try to avoid or defer implementing the feature in the first place. You will probably want to discuss it more deeply, and understand how it influences the bigger picture.
It may not mean you will get more responsibility (but you might), but you will certainly feel more responsible for the end product.
Also, it means you won’t get to complain about the uselessness of the new feature the Product Owner came up with :-). You may feel the need to discuss it instead.
Ultimately, you might see that you spend less time doing the actual coding. You might need to fight your internal developer’s instinct to start the implementation right ahead.
Objectively, it’s always better to avoid work that was unnecessary in the first place. Nevertheless, you need to keep in mind that your usual workflow might be affected.
But why would others care about your opinion?
You may feel comfortable giving clients/stakeholders technical advice. You have the expertise, and you’re pretty confident when it comes to the “how to build stuff” kind of questions.
You may well think that you have great ideas on how to put the project on the right track. But you feel this is above your pay grade. There are other people whose job it is to think about this stuff (CEOs, Product Owners, etc.).
They have more experience and know better — they wouldn’t care about your opinion, right?
Well, they probably should — and is most cases they will. Why?
You know the project
Photo by Slim Emcee (UG) the poet Truth_From_Africa_Photography on Unsplash
By the time you spend months working on a product, you get to know the system pretty well. Chances are, you understand the business domain too.
If you think about it, you are one of the people who know the most about the product your team is building. You might not know how users use the product, how it ties into the company strategy etc., but that’s fine. Other people on the team (UX/PO) have these insights and can use them to make decisions.
But you do have a unique point of view on the product. You know how it’s built. You know what’s easy and what’s difficult to add.
For example, the product owner might have an idea for a feature, but assume it’d be a huge effort to build it — so they won’t even bring it up. But you could know a way to do it in just a few lines of code — an effort that may actually make it worthwhile.
Of course, it’s best when decision makers have good intuition on what’s easy and what’s hard. But even if they do — they will never have quite the perspective you have. Make use of it.
You are an expert in building, and using, the technology
Photo by Neil Soni on Unsplash
Software developers are, for the most part, digital natives. It means we use multiple digital products and feel comfortable in the landscape riddled with apps and SaaS.
We often have specific needs and use cases — so we spend a lot of time mastering the tools and applications we use on a daily basis. This is our area of expertise, so we might take the time to figure out how these services work under the hood.
Software developers know and use a lot of digital products, so they get to know a lot of best practices, even without realizing it. We interact with multiple UIs, so we notice things that are annoying.
It would be a shame if we didn’t use this expertise when building products for our clients.
There is one caveat, though. Software developers should be considered “power users” rather than your average users. We need to understand that this perspective might be biased.
It is tempting to assume it is decision makers’ job to ask us for our opinion and incorporate our feedback into the product development process.
It may very well be true, but we need to communicate that we think about the product and have ideas we want to share. The more aware the Product Owner is of that, the more likely they are to solicit our input — widening their perspective in the process.
Also, have them read this if you can.
If decision makers do not want to hear what the wider product team has to say, it’s definitely a red flag for the success of the product.
There is one more thing to keep in mind. Disagreeing with the Product Owner and undermining their ideas might hurt their egos, so you need to be tread lightly and be empathetic.
Objectively speaking, though, they shouldn’t get defensive — it’s all about making the product successful. We all need to make sure the best ideas win, regardless of who came up with them.
If they do get defensive, or don’t care about your opinion at all — that’s another red flag.
When should you do this?
Of course, not always will there be space for us to engage in product development process. Some environments will only allow software developers to write code from specs, while others are more conducive to having them influence the whole product.
We need to make sure we can help and make meaningful contributions before we decide to invest in that.
While there are no hard-and-fast rules, and it all is a spectrum, there are some general features of environments that are more likely to let you engage in the process on a more strategic level.
You will have more chance to succeed in favorable circumstances, such as:
- Smaller projects rather than huge ones,
- Newly formed product teams, rather than those that are stable,
- Agile environments, rather than ones with strict schedules and roadmaps,
- Products where quality is more important than time to market,
- Projects in exploratory phases (as explained in Kent Beck’s 3X model).
This is not to say you have to be working on a project that meets these requirements to think about engaging in product strategy. However, if you are interested in product development, and the environment in which you are displays these characteristics, it’s very likely your perspective will be helpful and welcome.
How do we start?
Photo by Jon Tyson on Unsplash
So far, we’ve discussed why software engineers may want to engage in the process of creating tech products on a high, strategic level.
But how do we actually go about doing that? That’s what we will be focusing in the next parts.
First, we will learn what Lean Software Development is, and how we can apply its principles to think about the product, generate new insights, and develop a new perspective to look at the products we build.
Then, once we know how we can think about the product, we will see how we can share our ideas with clients and stakeholders, and work with them to develop better products.
See you soon!