Generating value for your software users

How We Plan for Value Generation

Many of our Backlog and Cacoo users both in Japan and overseas have given us some positive feedback about how our products are not only easy but at the same time fun to use. As engineers, it is important for us to routinely brainstorm for and create application features that users desire and can benefit from. Concrete processes, practice or technology being used will vary across different software categories but as long as we are developing software as a business, we will all need to have an idea on how to generate value. In this post, I will share about how we at Nulab plan and create value for application users. 

Spec-change Allergy

If you have ever developed software on a contract basis, the term ‘specification change’ may bring some frustrating memories to your mind; a barrage of calls from clients in the final stages of development, an unending development process, and a severely worn-out team. I had at some point as an engineer been involved in a particular project that consisted a slew of specification changes, which were tiresome and which subsequently led to long discussions with the client going over excruciating details to avoid further spec changes in future. 

Back in those days, I did so to avoid troubles such as a delay in schedule or a budget overrun. On top of that, I did honestly believe that that was what the client wanted. Now, I can assure you that it was not. In fact, it must have been equally difficult for the client to answer a truckload of extremely detailed questions while I determined whether a specification was right. I was expecting the client who was an amateur in system development to make an expert-level evaluation of the specifications that we have created with our best efforts.

In retrospect, the approach was obviously inefficient and possibly even counterproductive. However, I could not realize it at that time because I was obsessed with the idea of creating a spec that did not require any reworking. This obsession left me with a spec-change allergy.

Nobody Knows the “Right Spec” at the Start of Development

I loosely define “right spec” as the specification that provides value to users of a software. This value includes a perspective that creators want to deliver to users through their software as well as the software’s functionality. It is barely an exaggeration to say that the success of a software product depends on whether it can provide such a value. 

Although I have referred to my clients earlier, it is also common that even we, as developers of our own products, do not have a clue if a particular specification is right until we actually see it. No one would be able to determine whether a specification of a software is right when they have yet to see it, because even the developers who have been engaged in its development wouldn’t know the answer.

What are we supposed to do then?

Some of you may have noticed that the answer to this issue lies in the agile methodology. This means that we can improve software little by little to the “right spec” by repeating short iterations and quick feedback. In other words, making changes to the product is an essential process in determining the value of the product.  

Yet, even when you know that improving your software during development is an important process, it still isn’t easy to know exactly where you’re headed off to. You might be at the crossroads, and there are not many existing guides around that describe development processes from this point.  

Which Way is Tomorrow?

Here, I will share with you the steps that we take to decide where our direction lies. Basically, we carry our development through the following steps.

Let’s look at the notable points in each development stage.

What do We Want to Develop?

First, we consider what we want to develop from the following perspectives:

• Users
• Ourselves 
• Trends

We use Uservoice as a platform where users can report bugs or request improvements and new features for our software. We also use our own project management tool Backlog to manage inquiries and requests from users which saved as issues in related projects, all of which are then shared across the development team. This management process enables the entire development team to review all inquiries, and the respective engineers can have communicate directly with users if necessary. Some choose to avoid such an approach, as it can add interruptions to an engineer’s work. We however believe that this would help increase an engineer’s sensitivity to the perspective of users. 

On a regular basis, we also hold user meetups at which users of each product can meet with our engineers as well as our marketing team and share direct feedback and suggestions. Being able to meet our users in real life helps us realize deeper responsibilities and gives us greater motivation to constantly improve our products to make them more beneficial and useful to these people that we have met and gotten to know.  

The second perspective identifies with the needs of the creators, which is ourselves. As heavy users of our own products, we quickly realize the areas that are lacking and need to be improved. For example, a repeated operation, we realized, can be simplified with a single link.  

We also keep our eyes on trends of web services, discussing aspects such as function and user interface of consumer applications such as Facebook, Twitter, Google Apps and similar services despite the fact that we develop mainly B2B products. Considering that these services are widely used all over the world, taking these trends into account will help us determine a direction for our services in a broader perspective.

It is a common tendency to presume that our expectations and wants are no different than those of our users. Afterall, we are users of our own software products. This often leads to a self-assertion opportunity where we will never reach a fruitful conclusion. 

We need to first recognize that users are completely different from us. We need to admit that some users even hate what we like. I think that a good developer should know this on both an emotional and a logical level however challenging it is. 

Deliberating three perspectives, that of users, ourselves and external trends, helps us find objectivity in our ideas. 

Visual Over Verbal

There is a huge distinction between a picture conceived in your mind during software development and the actual appearance of the product. When we think about a specific specification to close this gap, we often start by creating a mockup (screen image). Although we design other things like data design when needed, we usually coordinate features required to maintain the consistency of functions little by little in a mockup-making process.

With a geographically distributed development team, we often create our mockups on Cacoo, our own online diagraming tool that facilitates remote collaboration. That said, you can virtually use anything (e.g. paper, white board, or Power Point) to visualize your ideas and share it among your team.

The biggest advantage of creating a mockup at the beginning is that it helps reduce the discrepancies in understanding between you and others, and it helps to make team discussions more intuitive and effective as visual materials also help to cut down on the number of things that need to be explained. Many of you may have experienced a situation where you were able to easily identify a bug with an image capture while it was comparably much more difficult to identify it with only written descriptions. Visual material surpasses writing in the amount of implicit information it provides.  

Another advantage in using visual material is that it allow us to easily identify features that does not tie in well with the others. It also lets you find out if a bunch of ideas are any good once they are put together. Being able to realize early on that you are on the wrong track can help prevent a fruitless investment of time and resources. This is especially important for small teams that cannot afford their limited resources to go to waste. Should you need to rebuild a mockup from scratch, little to no cost is involved as compared to reimplementing a development stage from scratch. 

Essentially, it is important for engineers to be engaged in design as much as they can in the development process. Even with dedicated designers around to do the job, engineers need to ensure that the designs are compatible with each feature and are able to convey functionality adequately. Otherwise, even if an idea is good in essence, it may fail to get accepted by the team when nobody is able to understand its value due to a design flaw.

Believing in the Power of Design

To illustrate the power of design, we will rope in one of the projects we were working on earlier which is the Git beginner’s guide. 

Nulab provides an online guide to Git called the Git Beginner’s Guide for Dummies. Our engineers originally wrote it using Sphinx, and a development team reviewed it on the HTML documentation that was created with it. Sphinx is widely used to create technical documents including Python, and its output is easy to read.

However, we had no intentions of releasing it without first improving on its design. We wanted to make a guide that is easily understandable and that would appeal to both engineers and designers who are interested in Git. Since Git can be seemingly complex to new users, we needed a design interface that can help simplify explanations and make the guide more friendly. In the design aspect, we engaged the following features:

• Simple layout 
• Bright colors
• Figures to aid understanding 
• An affable graphic character 

It took close to two months for us to complete it as we progressively added modifications based on feedback from designers who were new to Git and who tested out our guide. 

Since being published, our Git guide has had over 2,300 bookmarks on Hatena Bookmark, one of the most popular social bookmarking services in Japan, and is currently ranked third on Japan’s Google search results after the official Git website and Wikipedia. The huge popularity of the guide is undeniably due to the power of its design which has made it suitable and easy for anyone to read. 

Design by designers is distinctly different from those by engineers and others given their skills and expertise in the subject. They have been trained to express a product in ways that others won’t be able to. You don’t need to give designers specific instructions or design details because doing so may limit the effectiveness of good design. There are times when all I do is describe a certain function of the product, and the only thing I ask the designer to do is to make it great. Although this approach needs to be followed by occasional check-backs, I believe that fewer initial limitations on design would result in a better outcome.

Try and Try Again!

The book Getting Real, which summarizes the software development philosophy of 37signals, mentions that no one is able to judge a feature unless he or she actually uses it with real data. Getting real feedback by releasing a beta version in the production environment is much more effective than testing only in a testing environment. Our team members often say, “use it for real”. 

When it comes to change, it is not surprising to receive contradictory feedback. Naturally, some people welcome change and the excitement it brings, others develop a discomfort around it and prefer consistency or routine. Upon introducing new features to our products, we’ve received feedback like “I like it! It’s easier to use.” as well as some that resound with “I liked the previous one and I want it back.”. We need to carefully determine whether the latter simply needs getting used to or if there are underlying problems to the change. We are only able to find out the answer after users continue to explore the changes over time.

Releasing a beta version in a production environment induces costs as well. In circumstances when the likelihood of discarding a particular feature is high, we want to keep cost to a minimum. We have two approaches to test a new feature at minimum cost.  

The first is to build Chrome Extension from Google Chrome for a feature that only requires modification of clients, including improvements of UI and operational performance. With Chrome Extension, you can try most of the features that don’t require processing on the server side by using asynchronous communication, localStorage, and Cookie and manipulating DOM with JavaScript. The advantage of Chrome Extension is that it is much easier to develop compared to other browser plug-ins because you can easily build it if you are familiar with HTML/CSS and JavaScript. In addition, when you discover a problem, you can simply disable it. Also, you can easily test rough codes without bothering other users because these codes can be executed in your browser. If you share your Chrome Extension source directory, others can operate it by just downloading and enabling it and you will be able to get immediate feedback.

With the second approach, we gather feedback about features that require changes on the server from our employees who routinely use a beta environment server which we would have developed exclusively for them. We’ve built a process where you can deploy an application to the beta environment with one click from your browser so that anyone from the development team can quickly update the application when there is a defect or when an improvement is to be made. In this testing stage, a short feedback loop is more important than a perfect implementation. We try to reduce stress for our team members by separating the beta servers from those of production and allowing a simple deployment process in order to achieve an efficient feedback loop.

After a long process of trial and error based on our own experiences, the team will have developed a level of confidence for a planned feature. Even if we receive negative feedback from users after the release, we will be able to deal with them constructively.

Three Questions to Ask Yourself

Although the above approaches can give you a fairly comprehensive assessment of how well your product is doing, it is important to check against three crucial points that you and your team must cover. 

1. Is This What Our Users Want?

As you think about a specification more and more seriously as an engineer, you may find yourself obsessed with a specification that is right for software.

For example, when you try to improve feature A, you may also consider improving feature B which is similar to A in order to keep consistency between features. Of course, there is an advantage of keeping consistency if these features have similar usage, and consistency may be important in maintaining the sophistication of your product. However, in many cases, users rarely concern themselves with the small details. Rather than disrupting usability in the pursuit of introducing multiple new changes or taking a longer than necessary development time due to the expanded range of change, providing a quick way to resolve or improve a specific situation easier is likely to be more appreciated by users. 

Engineers are often concerned by the over-arching goal of their software and may easily develop a bias which may interfere with current short term progress. This is especially true when you are involved in the development of the software. It is therefore a good idea to let a member who is not in charge to ask you this question in a team discussion.

2. Does it Resolve 80% of the Problems?

Extending on the common pitfall mentioned above which is the compulsive pursuit for perfection, here are some of the complications that arise from trying to achieve a solution that solves every problem. 

• Complicated and non-intuitive performance
• Awkward interface
• Excessive configuration settings

If you try to find a solution for everything including corner cases in which a specific feature is used, performance and interface may end up being compromised. 

In such cases, focus on a way to solve 80% of the initial problems related to the feature and leave the remaining 20%  to a separate solution. It is counterproductive to lose everything by killing usability in the attempt to resolve all 100% of the problems. 

3. Does the Product Have an Identity?

Obviously, it is important to ask yourself this last question. Nulab products are centered on collaboration and fun; they form an identity for the products and help us to remember that providing an enjoyable experience to our users is our biggest priority apart from functionality.

A product’s identity is ultimately an abstract concept. It may be difficult or may require a long time to build. I believe that making a conscious effort to discuss a product’s identity within the team would help nurture one more quickly and effectively.  

Facilitating Processes

For the process I’ve mentioned so far, I would like to also introduce three aspects that are essential in supporting them. 

Technical Capability

The first aspect is technical capabilities. For example, we achieved the above-mentioned beta environment for the Nulab team by combining various layers of technique including:

• Implementation of job pipeline in Jenkins
• Browser testing with Geb  (Selenium wrapper of Groovy)
• Deployment automation with Fabric  (deployment and server management tool of Python)
• Deployment of resources to AWS
• Switching  servers to connect based on nginx configuration and Chrome Extension

When you write an experimental code, you might consider writing it in a manner whereby it is easy to switch back and forth between the revised and the original in the event that you need to adjust a specification. In this process, we need to have a design perspective in addition to simply writing functional codes.  

In any case, it is necessary for us to have the technical capabilities in handling various layers of techniques as a team and to routinely integrate those techniques into our own processes. Besides putting a high value on processes, improving individual skills is a basic yet highly important aspect for engineeers.  

Embrace Constructive Discussions

An engineer can tend to be slightly partial towards their own creation. While it is important to believe in your own work and inspiration, it is also necessary to be capable of evaluating them critically.  

In a featured interview View Things over Someone Else’s Shoulder, the President of Nintendo shared about Shigeru Miyamoto, one of the creators of Mario Bros as follows:

However experienced he (Mr. Miyamoto) may be, he never drops the notion that “If the players don’t understand it, there’s fault in the design I made”.

Of course, it is not always easy to carry such an applaudable attitude and to possess a sound acumen on every subject. Therefore, we try to incorporate the perspectives and ideas of others in the development process, and that is why I often mention discussions here. Our team operate based a mutual understanding of how constructive discussions are to be carried out: 

• The team shares a common goal
• Everyone has a fair opportunity to express their thoughts and opinion 
• Every opinion is respected

Such understanding gives us an exposure to ideas that are different from our own, and as we develop these ideas we can discover new ones that we would otherwise not have been able to conceive of.  

Willingness to Make Changes

One last aspect that supports the above processes is the willingness to accept and make changes. I believe that all approaches I mentioned in this article would work well on the ground of trial and practice. However, they are not complete.While writing this article, I am working on the development of an application environment for a release candidate which will then be released to users for feedback. It is necessary to be willing to change a process when you find a problem or a better approach or technique in order to provide a better software.

One Last Thing

“If you want to go fast, go alone. If you want to go far, go together.” (African Proverb)

As the Internet has enhanced individual capabilities, we have also started to hear about seemingly unprecedented achievements where “one engineer has changed the world”. Most engineers dream of such achievements, and we know that only a handful of them can manage to create a world-class software. Is it only geniuses that can take the spots of these handful?

The whole article that I’ve just covered emphasizes heavily on the repeated discussions involved in the process of value generation. I believe that even without outstanding ability, we can create a software that is world-class or even greater if individuals with a variety of capabilities, roles and values trust each other and are able to freely exchange ideas.