Blog

Introducing the Leonidas CodeBlog

Sunday, December 18th, 2011

Posted in Uncategorized | No Comments »

Answer the Right Questions with Prototypes

Friday, December 2nd, 2011

Prototypes validate ideas. Rather than basing plans on guesses, you create something concrete and put it to the test. But what kind of a test? That depends on whether you are aiming for a sustaining or a disruptive innovation. The distinction helps us ask the right questions and build the right prototype. As a consequence we eliminate waste and create an effective innovation process.

Sustaining and disruptive innovation

The division of innovation into sustaining or disruptive types comes from Clayton Christensen and his book The Innovator’s Dilemma. In brief, the theory states that incumbent companies constantly build better versions of their existing products. They become experts at serving their core customer base, but are not quite as good at serving new markets. This is called sustaining innovation.

Incumbents are vulnerable to disruptive innovation that can occur when someone else comes up with a whole new value proposal. The new product may be worse in many respects than the incumbent products, but it more directly addresses the needs of its market. Because the makers of the existing products see the market differently, they may not even consider the disruptor a serious competitor at first.

The difference between sustaining and disruptive innovation, thus, relates to the product’s value proposal. In sustaining innovation, the values are the same as those pertaining to the existing products. Disruptive innovation, on the other hand, uncovers a whole new set of values.

A textbook example is how the iPhone became the leading smart phone. Before iPhone, in 2007, smart phones had a rather small market. The most important and valuable features of smart phones were ordinary phone features, along with the ability to write emails and use a calendar. When the iPhone arrived, it was worse than the incumbents in many ways: it had poor sound quality, it dropped calls, it lacked 3G, it didn’t have a physical keyboard, and it was very expensive. So, to the core group of techno-savvy business users, it was not nearly as attractive as the other choices. However, it had certain benefits that made it attractive beyond the traditional core group. It had a user interface that was a delight to use, it acted as an iPod, and it had the best web browser on the market. It was a new kind of smart phone for a new kind of user.

Both disruptive and sustaining innovations have their place. Markets and competition are marked by short bursts of disruptive innovation, followed by long stretches of sustaining innovation before the next disruption. After the disruption in 2007, the smart phone industry has seen four years of sustaining innovation. Practically all current smart phones now look like iPhones, and they are all better than the original iPhone. The competition is about who has the best features and the best specs; that is, who can generate sustaining innovation.

Coming back to our subject, when we create a prototype, the distinction between sustaining and disruptive innovation is important to us. We should know why we are doing it, and what questions need to be answered. This depends heavily on whether our innovation is sustaining or disruptive.

The questions in disruptive innovation

When creating something disruptive, everything is uncertain. We have an idea for a new kind of service or a new kind of customer that we are going to reach with our product. Yet, we don’t know for sure whether the targeted customer has any desire for what we are planning. So, we want to make sure that a market exists for our product.

Examples of questions to ask at this point:

• Would anyone use our product?
• Would anyone pay for our product?
• Would the use of this particular product spread among customers? Would there be enough growth to sustain our business?
• If not this product, then what would make users happy?

Often, the best way to answer these questions is to build a prototype, show it to potential customers, ask the right questions, and listen to their feedback.

Qualitative feedback may be all that is required. You meet a few potential users, and see how they react. The caveat, of course, is that the use of the product during these interviews is not the same as real use. The consumers whose feedback is being solicited may feel the urge to please the interviewer with their answers, so their responses cannot be blindly trusted. Interviewing users is a skill all on its own.

It would be better to obtain quantitative feedback as well. Depending on the target market, it might be a good idea to put the prototype out into the world, market it to potential users (e.g. via search engine text ads), and see how many sign up. This produces a concrete metric for the degree of interest in one’s customer base.

The questions in sustaining innovation

Sustaining innovation is different. You already know the customers and what they value. You want to improve the product you have, or enter the market with a product that is essentially the same as that of the competition, only better in some respects. In any case, you already know two things: what you are comparing your product against, and what aspects you want to improve.

Prototyping has a place in this sort of innovation, too. The improved version has not been built before, and you are unsure whether it performs as well as expected. This uncertainty can be reduced by asking the right questions and then answering them with a prototype.

Some questions you may ask at this point include:

• Would this improvement produce the efficiency benefits that we thought it would?
• Would users choose our product over the competition’s product, based on this feature?
• How often would they use this new feature?

The questions depend very much on the type of improvement at which one is aiming. If a new feature is being created, the questions relate to the use of the feature and its benefits. On the other hand, if you seek to improve the production process, the questions relate more to efficiency, and so on.

Quantitative metrics should be used when answering these questions. For example, with regard to process improvement, you could measure the difference in the use of resources (such as time) compared to the original version. When planning a new feature, an alpha version of the feature could be released to a set of customers in order to assess how they use it.

Qualitative metrics have their use here, too. It may be expensive to build a sufficiently-good prototype to answer questions quantitatively at first. In that case, the qualitative questions should be posed first to decide whether it makes sense to continue along the current path, or to make changes. Then, a better prototype can be built to measure things quantitatively.

Eliminate waste

One way to look at prototyping is that it eliminates waste from the innovation process. At the start of innovation, the most important result of one’s work is information: i.e., whether the current idea works, and whether it can be improved. So, what creates accurate and relevant information is valuable; what does not, is waste.

Instead of paying, and waiting, for an entire product to be completed, the construction of a prototype will help you to answer the questions quickly and effectively. However, it is not enough to build just any prototype. Ask the right questions, and you will eliminate a huge amount of waste. It is important to know whether your innovation is sustaining or disruptive. The questions are different, and the prototype will differ accordingly.

The division between sustaining and disruptive innovation is just one factor that can alter the questions to be answered. It takes skill and experience to know what the right questions are, and to build a prototype that best addresses those questions. We can help you.

Posted in Uncategorized | 3 Comments »

Frozen Rails 2011

Tuesday, November 29th, 2011

In September we had a week of conferences. Leonidas sponsored Tampere Goes Agile here in our hometown, while Edvard and Janne traveled to Strange Loop in St. Louis, and Sami visited the ICFP conference in Tokyo. Meanwhile, Toni and I went to Frozen Rails in Helsinki to hear the latest buzz from those in the Ruby on Rails world. We decided to look back on our Frozen Rails experience.

One of the sessions we most looked forward to was Jeff Casimir’s talk entitled “Blow Up Your Views.”  He called for a better separation of views and business logic. We had already been going in that direction in our projects: minimizing data transfer to a plain template and JSON while letting the browser do the rendering. Jeff’s presentation entertained us quite a bit and merged well with our view of how web software should work.

Are developers also designers? Developers should have at least a basic knowledge of design to avoid pitfalls because software is valuable only if it is usable. Jarkko Laine’s talk entitled “Full Frontal for the Backend Pack” was a reminder of the importance of interaction design in web apps. One of the things he talked about was using HTML5’s History API to maintain linearity in browsing, which is exactly what we have been doing when moving a rendering to the client side.

We were excited to hear Zach Holman talking about maintaining flow at GitHub. They avoid metawork, work asynchronously via Git, and use a simple branching strategy similar to ours. But above all, they love great software and creating it, as do we. We don’t go as far as communicating with pull requests to avoid interruptions, but we do have the ticking of a Pomodoro timer to indicate flow. Some parts of the GitHub method probably work well only when you are developing something like GitHub though.

The guys at GitHub presented another session towards the end of the conference, and Aman Gupta gave the most information-packed talk of the conference about debugging performance issues in Ruby. In a little less than an hour, he introduced us to a dozen tools, providing brief explanations and use cases. Obviously, we didn’t have enough time to learn everything there is to know about the topic, but he gave us a good idea of what tools will be handy and where to look for them.

It was nice to note the feeling of connection and unity within the Rails and Open Source community. The atmosphere felt very casual, and it was easy to strike up a conversation with just about anyone. We returned to Tampere feeling invigorated and excited.

Posted in Uncategorized | No Comments »

The Value of Values

Wednesday, November 2nd, 2011

What would you do in the following situations?

1. You think you should add memory to your laptop to make Scala development on Eclipse less painful. Who should you ask to order it?
2. A customer wants a new feature, but you think the feature is useless. On the other hand, it is a big feature and would let you bill the customer for two additional months. What should you do?
3. You’ve played with Clojure during your free time, but never used it in a project. A new project is starting, and Clojure sounds like a good choice for it. Should you use it?

Pose these questions to different people and you will get very different answers. In Leonidas, though, most people, if not everyone, would answer along these lines:

1. Just order the memory yourself with your company credit card.
2. Talk with the customer about the feature. Try to understand his point of view better, and explain why you don’t see value in the feature. Let him know it is important to understand exactly why the feature is needed, so you can do a good job on it.
3. It depends on the details, but you should definitely not be afraid to try Clojure if you think the company would learn something useful from it.

If you work at Leonidas, we want you to make these kinds of decisions on your own or within your team. You do not need to ask your boss for permission (in fact, we do not want there to be that many bosses either). On the other hand, we want there to be common answers so that you feel you are safe to make choices and so everyone has an idea of how the company works in general.

The point of values is to remove barriers from decision making. Leaders make sure that values are understood, respected, and followed; not direct and tell how the actual work should be done.

That is why we make a fuss about values. We talk about them often. If something surprising happens or something did not go as well as we hoped, we ask, “Did we follow our values?” If there is a big disagreement over something, we ask “How does this decision mesh with our values?” And to remind ourselves about our values before anything like that happens, we ask “How did the values manifest themselves last week?”

Leonidas has three values: trust, candor, and kaizen.

Trust means you let other people do their work and do not micromanage. The company needs trust to work productively and creatively. Ordering the laptop memory by yourself is an example of trust. Others trust you to make the right decision and not abuse the power.

The other side of trust is that you can be vulnerable, without fear of ridicule. We understand that everyone is human and everyone makes mistakes. When you are open to the fact that you do not need to be perfect, you are open to honest communication and actual improvement.

Candor means sharing your thoughts. It is more complicated than just saying whatever you are thinking; your goal is to make the other person understand what you are saying. The answer to the second question above is an example of using candor: You tell the customer of your doubts, even when remaining silent about how it would benefit our company in the short run.

Kaizen is Japanese for continuous improvement. It means we will always be looking for new ways to improve all layers of the organization. For example, we often speak of “making the wow” when we present the results of our Protosonni. Kaizen means we are not happy with “the ordinary wow”—we want to wow ourselves in addition to the customer. The hypothetical usage of Clojure is an example of kaizen: Learning new things is valuable to us; therefore, we try out new things.

Our values form a kind of cascade. With trust, you can be candid, speak your mind, and know that others will not hang you if you happen to say something wrong. Trust and candor enable kaizen: When we are able to talk about anything, hard issues can be touched and improved.

Everyone enjoys their work more when they have the control over it. Shared values let us give control to where it belongs.

Posted in Uncategorized | No Comments »