Introduction In 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. previous parts Now, we will discuss how we, Software Developers, can have an impact on the product we’re building. even greater Previously, the subject we were concerned with was giving advice on “ . Now, we will switch our focus to a much broader, strategic questions like how should the feature be built?” “ 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 , we’ve discussed why software developers might want to become more than code monkeys on their projects. first part 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 on Mikito Tateisi 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 challenging. that The client may want us to build yet another app in Rails for them. Or maybe they need to have some documentation prepared. We’ve all been there, right? CRUD Whatever it is, I’m sure you agree that some aspects of product development can get a bit mundane. We that they are crucial, but still, we can’t quite enjoy them. know If you switch your mind to thinking about the product — a new world of challenges opens up. There are a lot of difficult problems to be solved there: as a whole “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 on Ali Yahya 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 on Sharon McCutcheon 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 , so all software products need to keep users in mind. someone 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 on Hermes Rivera 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 . 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. passionate about the product 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 on Samuel Zeller 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 on Hubert Mousseigne 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 or implementing the feature in the first place. You will probably want to discuss it more deeply, and understand how it influences the bigger picture. avoid defer It may not mean you will more responsibility (but you might), but you will certainly more responsible for the end product. get feel 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 to think about this stuff (CEOs, Product Owners, etc.). whose job it is 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 on Slim Emcee (UG) the poet Truth_From_Africa_Photography 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 on Neil Soni 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 if you can. this 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 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. have to How do we start? Photo by on Jon Tyson 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. 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. First, we will learn Then, once we know how about the product, we will see how we can our ideas with clients and stakeholders, and work with them to develop better products. we can think share See you soon!
