The technical manager’s guide for building internal software products

This article is intended for technical managers from the software industry. Other related roles (e.g. product managers, product owners, etc.) from this industry or similar industries may also find the presented information applicable to them. In the next paragraphs, I’m gone try to write a few tips and trips that the above-mentioned roles may find useful in implementing and promoting products intended for internal consumption within the organization. These products are usually libraries or frameworks or even fully polished end-user tools that other groups will use in their daily activities.

I’ll try to keep the guide generic enough, but I realize that may not be applicable to all organizations. If you’re reading this article, I’d be interested to receive your feedback about what works and not for you.

Obtaining the approval

Building a product starts with a vision. A new product creates a sort of excitement that drives you to implement it. But before that you need to obtain the approval from the product owner or upper management.

Only then, you can place the product on the roadmap and start executing the implementation. There are two main ways to get the approval:

A few words about communication

Always use careful and clear communication when you want to transmit your ideas. You can communicate your idea directly in a 1 to 1 meeting or via email. Sometimes the corporate structures make difficult direct communication, and then the email is the only solution. Let’s say you write the big email telling management about your idea. You sit at your computer and craft that email to perfection using the best language and provide the right details. You’re very proud that you wrote it and you expect that the recipient to answer back congratulate you and give you the approval!

Let me bring you back to reality. It is best to set your expectancies right since you may not get an answer back! This is normal. Many busy executives and managers don’t get the chance to read all the emails. And even if they do read the email, if your idea is not clearly articulated or is outside the usual range of business problems, executives may skip yours and move on to more critical emails. If you don’t get a response back in a reasonable amount of time, don’t get disappointed or jump to conclusions that management ignores you. Instead follow up with them to make sure they got your message. Sometimes is necessary to follow up several times until you get someone’s attention.

Build the product

Let’s assume you got the necessary approval and resource commitment and you start planning to build the product.

You go in the feasibility phase, build a POC and things look good. After POC, you may start planning on the development considering all the bells and whistles you’re envision for the product. You work with the PM, put a project plan in place and realize that the development alone will take 2 years.

At this point I must stop you.

Before going on that 2 years journey that may turn out to be 3 years, it is best to look at producing a prototype or at least a minimum viable product. It is recommended to find a small set of users in the other departments that can help you build the product by providing valuable feedback. If you’ll be able to build a product to satisfy the needs of a small group of people, you’ll be able to extend that product in a future version to satisfy the requirements of a larger user base.

Even better, the first user of your product should be you and your development team. In this way you’ll be able to identify those critical features that needs to be in the product in order to function. Doing this will avoid frustrations with your users later on. In other words: “Drink your own kool-aid”. This is a very good strategy that worked for me and my team many times. We were designing a framework and designer product at that time, and the original shape of it has been driven by our own usage. We were constantly using the designer and framework to design new UI forms. This exercise helped us put in the designer those required features that otherwise wouldn’t allow us to build proper UI forms.

Stand behind your product

Hooray! You released your product and is time to celebrate… and why not start looking at the next opportunity!

This is a very big mistake! Not the celebration part, but the assumption that your role is over. The product needs to get the proper adoption in your organization in order to consider it a success. Otherwise it will be abandoned, and it will be classified as an unsuccessful project.

Well… there be exceptions here. If the product has upper management support, then they will ensure the adoption and your role post release will be much easier.

However, in many complex organizations, individual departments have the freedom to select their own framework and tools. If that’s the case, and if upper management doesn’t back you up, then is up to you to market your product with different groups.

You may be tempted to ease your work and find someone to act as an ambassador with the other groups. Don’t do this. The first ambassador for your product should be you! In time, you may get the help from other people that will help you promote the product. But initially you should get the ball moving.

Market your product

Don’t assume that once your product is ready people will show up on your office door! They don’t! Why they would show up unless it is a really an extraordinary invention (rarely happens) or someone else forced them too.

Even if you build a framework easier to use then React, or a ticket management system better than Bugzilla… people will be hesitant to adopt your product. They don’t know anything about it.

Don’t assume that if you put the information in your release notes, user manual or SDLC documentation your users are informed and trained, and your job is done. Users rarely read those documents. Instead try to communicate the details to your users in a direct and genuine way.

Always transmit information via multiple channels: webinars, emails, phone calls, etc. And always restate your message. People rarely gets the message from the very first time.

Don’t assume people got the idea from the first email you sent them. Emails sometimes don’t get read or even if they get read people may not understand what you are talking about and they may move forward with their daily tasks. Follow up with your audience. Many people assume that if their users didn’t answer back to their email from the beginning, they are ignoring them. That’s far from the truth. In many cause managers or highly productive users have a backlog of hundreds of emails and is very easy to skip an email. That’s why is important to follow up to make sure they got your message. Sometimes is necessary to follow up several times until you get someone’s attention. Do you realize that I’ve give the same advice that I gave at the beginning of this article?

Also remember that communication is happening between two parties! Don’t automatically classify the recipient as insensitive to your message. Instead focus on the transmitting side too! Try to change, tune your message until you’re sure it is well understood.

Support your product

To ensure the good adoption of your product you need to take care of user training and product support. I’m not referring to the formal training and support that your company is putting in place after a product launch … but to that personal and genuine training that you need to offer to your users in order to make them adopters and big proponents of your software! That kind of training that only you that have the complete vision can deliver! Training helps with the correct adoption of your product. If a product is incorrectly adopted it will backfire. Users will not understand how to use the product and will be frustrated. They will send negative feedback to management which in turn may terminate your project. Also consider training even the non-technical roles that get in contact with the product. These people are easily forgotten and not included even in the formal company trainings. If they manipulate your product, they have the right to know more about it.

Here are a few tips to help you with product support:

Create a Technical Bulletin. A Technical Bulletin is a great vehicle to keep your users informed about new releases but also offer tips and trips about existing versions. Remember however that one thing that aggravates people most is another email … especially a very formal corporate email! Therefore, try to maintain a friendly and laid-back language in your bulletin. Address to the user and answer to their needs. Be genuine. Even consider implementing a “Funny Corner” section in your bulletin to publish a joke / game or funny image (assuming is appropriate for work).

Create a Screencast Production Studio. Video is one of the most efficient ways of transmitting information – not to mention that is highly popular for tutorials and other kind of trainings in this day and age. To produce a screencast is unbelievably easy! It is in many cases much easier that writing an article or create a PowerPoint. Also sharing a screencast (which is in fact a video) is so easy! Don’t try to attach to video to an email… instead look for an approved video sharing solution within your organizations. Microsoft Stream is a very good sharing option for internal video distribution – and you may already have it (as is part of Office 365 that many companies are adopting)

In the very simple form, a screencast is just a recording of your screen. There are plenty of software programs that can help you with this. With a little bit more effort you can however incorporate also the presenter in the screencast. This helps the viewer connect with the presenter. SmartPhones makes this very easy today. Do you realize that you’re carrying a full-feature camcorder in your pocket? Just find a quit office or conference room and record yourself (or a team member) transmitting a message about your product.

After you made a few screencasts using your phone, is time to look at bumping up the video quality and also to help others adopt this screencast method for transmitting information. I’m sure a lot of piers will ask you: how did you do that screencast? At this point I recommend looking around your company and identify an empty office or corner that you can take over it. The goal is to transform that empty office into a Screencast Production Studio that will make recoding a breeze. Since you’ll setup your studio with fixed lights and camera, there will be no setup involved in producing a screencast. Just show up, record and share.

I will close this article here and invite you to experiment with some of the tips I provided here. If things don’t go as planned, remember that adversity builds resilience.

Don’t forget to share your experience or provide feedback.

Article inspired by writings of Paul Graham and my own experience.

15 Mar 2019