Top Seven Soft Skills For A Product Developer
A lot has been said about skills of a product manager. No doubt it is a highlighted position in any product company. However the majority of work actually happens in the engineering labs, where the product takes shape. The abilities of the product developer can greatly influence the outcome.
Beyond the technical skills required for development, which can also vary by the product being developed, a number of soft skills play a very important role.
In my many years of work experience, developing software product, I came across a few skills worth mentioning. I have also narrated a few experiences during the journey. All Names have been changed to ‘Cal’ in order to protect the identity of past colleagues.
Wikipedia defines Empathy as
“the capacity to understand or feel what another person is experiencing from within their frame of reference, that is, the capacity to place oneself in another’s position”.
A good developer has to understand the real pain points of the end user, and address them exactly the way user expects it. A technically best solution can fail in the field if the implementation does not resonate with the user. Many times the user does not know, or is not able to express the exact needs, and the ability to read between the lines becomes very critical.
‘Cal’ was working on a reporting engine. It was very quick and easy to come up with a simple user interface that would allow the user to choose the type of report, such as tabular, graphical, and select the data to be shown by selecting columns. It has been a common practice, and such a UI can be seen on many existing products. However Cal was restless. Is this what the real user wants? The real user is not a computer professional; that means there is a need for someone with skills to help the end user. No, No, that doesn’t sound right. Cal spent days interviewing user, and figured out a completely new interface, that was specific to the product in question. Great job! Cal.
“Know what you are doing, and also convince others”.
On any complex topic, there are always multiple opinions. Which one is right?
Once a developer understands the problem and evaluates options to solve it, there is a need to pick an optimal solution for implementation. It is important that one performs this exercise so carefully and thoroughly, considering all the available options, that once decided it should be possible to convince others.
An assertive developer will not budge under influence by others, because the conviction stems out of research and is backed by past experiences.
The ability to say “NO” to something that is not required can save a lot of valuable time and dollars.
Recently Cal was asked to start working on a new feature. This feature is extremely important for the customers and getting it out the door in the next release would mean a lot to them. There was always pressure to get it done sooner. However Cal realized that the new feature depends on a critical enhancement to the existing functionality; which was not planned. Anyway Cal could have started that feature but he would not be able to complete the work to the satisfaction, resulting in a poor job. Cal not only resisted the inclusion of this lame feature, but also convinced the management to include the required enhancement in the next release so that a much stronger output can be expected in subsequent plan.
Releasing a product is a complex process, and a lot of planning goes into making a release successful. Many times there are dependencies on external factors like inputs from third parties or event deadlines. A slight delay in one deliverable can cause a cascading effect on subsequent ones.
As it is critical to complete tasks on schedule, it is even more critical to report on any deviations at the earliest opportunity. If a task is delayed, and the delay is reported on time, it may be possible to rework the schedule, reassign some of the tasks, drop a low priority feature, or get some external help.
4. Working under pressure
“It is the last push that delivers => In agile development deliveries take place so often”
Gone are the days, when it took nine months to deliver a baby. Well a human baby may still take that long, but the harsh fast moving world, software products are delivered much faster and more frequently. For the developer it means working continuously under pressure with minimum time for rest. Like a heartbeat, the developer needs to be kicking all the time between periods of extreme pressure and less pressure. It is also a lot more satisfying act showing quick results for actions.
5. Eye for details
“There are no big-mistakes, only small mistakes that can cause big losses”
Well, well, well! When the mistake is big, it is very easy to find and fix. Everyone can see it. However when it is small, it is easy to miss it! Only a careful eye that cares about all the finer details can find it.
‘Cal’ is a fast mover and is always ahead of schedule on his individual deliveries. However in hurry to move forward he used to miss on small (as per Cal’s view) things like finer alignment of controls on screen, right font selection etc. Though this will achieve the required functionality, it will create a bad first impression for the viewer. ‘Cal’ was so much focused on the functionality, that he never gave enough importance to the look and feel. Not just on the screen, but it reflected in behavior quite often. It took quite some time for Cal, to understand the importance of finer details, but once he got it, it was not very difficult for him to implement. In our development team Cal was paired with and supported by Jim, who had the required eye.
“Alone we can do so little, together we can do so much.” — Helen Keller
A successful product cannot be built without great teamwork and coordination.
Everyone in the team is bound to have a different perspective on any aspect of development. Teamwork means depending on each other’s resources, let the right person do the right job; help each other when stuck; argue about issues to find a solution, but never make it a personal issue; Be aware of egos of individuals, and respect their personalities and habits. A lot has been written about teamwork.
‘Cal’ is a fast mover and is always ahead of schedule on his individual deliveries. Once finished with own work, Cal would always work with slower members of the team members to catch up, by reviewing their work and providing them pointers. Cal was a great addition to the team and everyone respected his views, and tolerated his attitude because of the help he provided.
According to Andy Grove, founder and former CEO of Intel,
“Success breeds complacency. Complacency breeds failure. Only the paranoid survive.”
A product can fail in many ways. Some of the failures are caused by bad development and can be avoided if handled right from day one. With experience the developer can become over-confident about the quality of code. A good developer will sense this and build in extra defenses in the product to handle such situations.
Cal was developing an android application, which maintained a copy of its data as a backup on the server. The application was expected to copy the data periodically and also check the integrity of the copied data. For some business reasons, it was important to maintain the copy of data on our own servers and not just rely on default backup mechanism of android. As a normal Android developer Cal had taken enough precautions to ensure correctness of the code. However, Cal also thought it was necessary to double check the integrity of the data residing on server, and created a server side daemon, that will periodically check data stored on backup devices. This small extra step will ensure that the data is available when needed.
To sum it up…
Technology is at the core of products, no doubt. However it is also true that success is one percent inspiration and ninety nine percent perspiration.
Building a product organization is tougher than building a product. Selecting the right team members with the right skills and attitude and help solve the problem better.