Showing top 0 results 0 results found
Showing top 0 results 0 results found
There are a ton of different ways you can take on software development. Depending on whether you are preparing your own product or you offer software development outsourcing services for specific business customers, you can either use various agile methodologies or devise a plan with a customer and stick to it over the course of the development.
Different methods will produce considerably different results. When working within an agile framework, you’re able to adapt your approach as you go but it can prolong the development. While working with a plan, you will be able to work well with deadlines but if anything comes up, you won’t be really able to react.
Karolina Urbańska, LiveChat’s Product Owner, shared some great insights into how we come up with new feature ideas and how they are brought to life.
See how we tackle software development at LiveChat, what methodology we use to prepare our customer service software and what results we are getting.
Product development at LiveChat at a glance
Before delving deeper into our product development, here’s a quick summary that should give you a rough idea on how we work.
First of all, everything starts with a plan. We have one grand plan for what we want to achieve and how we want to do it. The plan is divided into smaller, more manageable steps.
Secondly, we gather all the customer feedback we can get when doing research. It gives us a solid background and allows us to see if our ideas make sense.
Finally, until recently, we didn’t use any agile methodologies like scrum. Instead, we aimed for weekly feature updates so that our users have always something new to try out.
How other companies are doing software development
At some point, we recognized that this may not be the best way to approach software development. We decided to change a few thing to make the whole process more flexible and smooth. We also wanted to check how other companies are approaching software development.
We got in touch with Monterail, a neighbouring Ruby on Rails development company and it turned out that they have a completely different approach to development. Since they don’t create their own software but develop software for their customers, they need to have their customers much more involved in the projects. In their workflow, they embrace the scrum methodology and sometimes even have customer participating in their scrum sessions.
Even though we don’t use scrum, we do like to hold daily update sessions. During these sessions, our developers get the chance to tell others about their progress.
Since we are working on our own software product, we have much more freedom. It’s very important in our case because it allows us to remain very flexible and adapt when necessary. Instead of working with a set plan, we work with rough, strategic outlines. The end product can turn out a bit different than we initially imagined but, in the end, it will resolve all the problems we wanted it to handle.
How to do software development research
Working on our own software is not without drawbacks. Since we don’t have a partner in the development (the individual clients in the case of software houses), we need to do the entirety of our research on our own.
Software houses have a lot of data at the start of a project. The business clients that they work with will let them know what are the biggest problems they want to resolve with the software and how it can be done. They can also bring experts on board from the client’s side to help with the development.
In our case, we don’t have anyone telling us how to solve the problems of our customers. And this can be both a blessing and a curse.
Here’s a couple of methods we use to get the research part of product development done on our own:
- A lot of 1:1 talks with customers: First off, we reach out to customers who need to solve specific problems. They usually let us know by contacting our support. We can then set up a quick call about their problems and how LiveChat can help with those problems.
- Gathering customer feedback via surveys: Since we can’t have 1:1 talks with all our customers, gathering customer feedback via surveys is another method we use. It allows us to relatively easily gather large amounts of customer data.
- Testing and observation during meet-ups: Whenever we get the chance, we try to visit our users. It usually happens at least once a year. During such visits, we want to meet as many customers and learn as much as possible. One of the most important aspects of such visits is seeing first-hand how people use our app. Seeing them work tells us what needs to be improved to make that work easier and more productive.
- Clients ‘hacking’ our product: There’s a group of businesses using LiveChat that created custom integrations or even features by ‘hacking’ our product to a certain degree. For example, they can display a lot of additional information about their customers in the app or offer a form a customer can fill out with each chat. To do this, these businesses need to involve their own development teams. The solutions they come up with are often a source of ideas for our developers.
- Coming against new problems during development: The development process itself can be also a good source of new ideas. We often come across problems we previously didn’t see or consider. The flexibility of our approach allows us to adapt to these problems and resolve them in the final version of a given feature.
When it comes to methods that we don’t use, we’re still on the fence with focus groups and card sorting.
Focus group research allows you to take the 1:1 conversations with customers to a bigger scale. Instead of getting the responses from one specific user or business, you are able to gather the same answers from a group of users.
Card sorting is a method that allows you to test if your users understand the way you’ve structured your product. It checks if the names and navigation scheme is clear enough that your users are able to use it well.
Although we don’t use these methods at the moment, we might give them a try in the future.
The importance of failed experiments in software development
Customer feedback can be an invaluable source of knowledge. However, you should watch out not to draw the wrong conclusions from the feedback you receive.
To better illustrate this point, here’s a story of how one of our more recent projects turned sideways because we misinterpreted the needs of our customers.
After a round of customer feedback, we got this idea to create an app for LiveChat managers. The app would provide basic information about a LiveChat account and offer reports for managers.
Back then, we thought that we should go for it since we had so many customers requesting such an app.
We created a mockup and a beta signup page for the project. We then showed the concept to our users. A lot of them were very interested and provided a ton of additional feedback.
After digging a bit deeper, we found out that the customers don’t really need another app for the chat data. What they really needed was an easier way to access the data. Creating an extra app was not the best way to fulfill that need. It was much easier to simply improve the access to reports instead of allocating the time and resources to develop a completely new app.
Additionally, a lot of our users were not aware of a Dashboard feature that was already available in LiveChat. It presents real-time data about a license, so it’s perfect for users looking for that kind of data.
We eventually cancelled the project, which led to a lot of customers getting upset. There are two lessons you can learn from this example:
- Clearly communicate what you are trying to do: We should let our customers know that we prepared a mockup and were only considering creating an additional app. Since we found an alternative solution to the problem, the app was no longer needed but a lot of customers were already sold on the app idea and got upset when we cancelled it.
- Don’t follow customer recommendations blindly: Sometimes, the ideas customers have may be good. However, you should keep in mind that there can a better alternative that will be easier to prepare or one that will solve more problems.
How to pick goals in software development
The Manager App situation shows how difficult it is to make the right decisions in software development. A solution that may seem OK can turn out to be only a partial fix of a much bigger problem.
When we decide on specific goals we want to achieve, we take several factors into consideration:
- Going by our gut: our team has decades of combined experience and it would be counterproductive if we didn’t try to use that to come up with new feature ideas,
- Support/marketing feedback: sometimes someone from the support or marketing teams will come up with a good idea and will pass it on to the development team,
- Customer feedback and feature requests: Our support teams passes on all the feedback and features requests our customers send over to make sure the development team has the full picture.
Going by our own gut and gathering ideas from support and marketing is pretty self-explanatory. We always go for what we feel will work best for customers.
When it comes to feature requests, our task is to discover the underlying problems and needs customers want to solve with the suggested feature. Once we learn about the problem/need, we are able to prepare the best possible solution for it.
When popular requests don’t make the cut
Even though customer feedback can be very useful, you still need to consider how costly it would be to implement the requested feature or if it provides enough value.
Sometimes even the most popular feature requests are not worth it.
In our case, this would be adding new notification sounds for our app. There’s a huge group of LiveChat users that would like to be able to modify the sounds LiveChat makes when a new users enters chat or writes a message.
The sheer amount of requests for this feature seem to suggest that we should start working on it immediately. However, when we did the math and calculated how much time/development it would take, we could list several features that would take less and provide more value.
In such cases, the best course of action is to go for what offers the most value for customers. Value-oriented development allows you to pick features that solve the biggest problems for the highest number of customers.
How our software development process looks like
Everything starts with research. Our UX team works closely with our support team to find out any new problems users want to solve with LiveChat software.
We look at how many times a particular problems comes up, we decide how important we think it is and check how many customers it affects. We then pick the most pressing ones.
Once we find something we can improve or fix, one of the first things we do is to decide on a KPI that could be used to measure the success of the improvement/fix. This is very important because you can easily end up doing a lot of development and not really know if you managed to make a difference or not.
Next, we mockup a solution for the problem and come up with a rough design. At this point, there is no ‘technology’ involved yet in the project.
Only when the design is ready, the development team is brought on board. They check if the idea can be done from a technological standpoint. Our support is also brought up to speed to check if the mockup solution solves the original problem.
When everything checks out, we move to development. A small project team is created. Usually, it includes a designer, a UX specialist and a developer/developers with expertise in the right fields. Before any coding stats, the newly-formed team meets up and discusses the whole idea extensively. They go through the original problem and the proposed solution to check if there is anything the could add or improve. All this shouldn’t take more than a week.
When development starts, we also start working on the necessary promotional materials. We create a mailing for our users, a post for our updates section, an in-app message that appears in our apps and sometimes we get in touch with users that requested a particular feature.
All this is done to make sure that the development time is not wasted. You don’t want to create a situation where your team spends a lot of time on a feature that will be used only by a couple of customers. You need to announce the new feature and make sure that everyone knows about it.
After the development is finished, we go through the entire project one more time. It’s a chance to discover if we managed to solve all the problems.
If nothing comes up, the feature is deployed. We usually start with our staging environment so that our support team can test it extensively.If you are a user of the app you create, you’re in a very good spot because you can test it first-hand. Using your own product is a huge benefit because you will usually know it inside-out.
At this point, we want the project to ‘age’, just like a good wine. All the problems that didn’t come up during development should surface when your team is testing the app. And since the software is not released yet, we still can easily make all the necessary fixes.
If after the period of internal testing everything still looks good, we release the feature to all users and we start promoting it.
There are usually several projects like this running simultaneously, both big and small, run by several independent teams.
What’s the measure of success in our product development
This is one of the most important questions you need to answer when developing software products: how can I tell that it works?
If you don’t set the right KPIs right from the beginning, you will only be able to guess if something worked or not.
This kind of KPI-oriented thinking gives you the means to decide if the time and resources you’ve poured into development were worth it. You always want to avoid a situation where you spend a lot of time working on a feature that ends up being not that useful for your users.
To make sure that doesn’t happen, we like to break our projects apart into smaller chunks. Instead of working on huge feature from start to finish to see what results it would bring, you can create an MVP (minimum viable product) and see how it fares. If it fails at this point, you can either improve it or drop the idea altogether and go back to the drawing board. As a result, you save a ton of time and trouble.
Software development tips
As you can see, developing a software product is full of small moving parts that need to work together to produce some decent results. A small change here and there can make a huge difference in the final version of your product.
Here’s a summary of the things we find most important in our product development and to which always stick:
- Plan ahead for goals you want to reach: Your team needs to be aware what is the end goal for your software and what steps you need to take to reach this goal.
- Gather as much data as possible: You need to know everything about your product. Don’t stop at using one source for intel. Reach as many customers as you can and find out as many uses cases to explore.
- Know when not to use customer suggestions: Even though customer feedback can be one of the primary ways you can get new feature ideas, you should use it wisely and only when it leads to solutions that produce a lot of value for customers.
- Remain flexible: During development, you should often check if the solution you’ve gone for is still the best option. Sometimes, it will turn out that there is a better alternative. When that happens, you should be able to adapt instead of starting everything from scratch.
- Don’t be afraid of failed experiments: Even the features that didn’t really work out in the end can be a source of valuable knowledge. Take note of the mistakes you made and make sure they don’t happen with the following projects.
What are your experiences with software development? Got any interesting methods to share? Feel free to add a comment as we’d love to learn something new!
Get a glimpse into the future of business communication with digital natives.
Get the FREE report
Comments