Product Development
now browsing by category
Tribes - A good exercise for team´s start up
Hi guys, this time I want to share an exercise for your new project ramp up. I think this activity is extremely important, because as Lyssa Adkins says “Throwing people in a room or holding a “kick off” is different than a good team start up”. Usually, when a team is formed, people do not know each others, so it´s always a good idea to create some activities that allow team members to get to know each other. The “Tribes” exercise is quite easy yet quite powerful, let´s see how it works…
You must have a big open area with enough space where people can walk around without a problem. After that, ask team members to share some ideas on the topics they are interested in loudly, so that everyone in the room can hear them. People that share same interests on the same topic join the person in the center of the room; this will form a small “tribe”. Ask other individuals to do the same and observe how “tribes” are formed and reformed around the new individual/interest. This is a great exercise that can be used as an ice-breaker activity. It´s always very interesting to observe people´s expressions when they realize that there are many people with the same interests. As a result, the group will understand the other´s appreciations better.
If you want to go deeper in the exercise, you can, for example,ask people to do the same with Agile Best Practices, so that all team members familiarize themselves with different agile skills of their team members. Below you can find few examples, you can create hundreds of them.
* All my tribe members that appreciate pair programming, join me
* All my tribe members that are specialists in TDD, join me
* All my tribe members that love Cucumber, join me
* All my tribe members that think retrospectives are a fundamental part of our project, join me.
I believe, using this exercise will create some kind of bonds among team members and will help them to understand where they position themselves, on personal level and/or on the technical level.
What do you think about it? Let me know whether you use it…
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Using VSM(Value Stream Mapping) as data gathering for restrospectives
Hi guys, in this post I wrote how can we use Value Stream Mapping as a tool to help with system thinking. Many people asked me if I could explain better what Value Stream Mapping is. Therefore, in this blog, I will give a short introduction about it and I will explain how you can use it as a gathering data for your retrospective.
Although value stream mapping is often associated with manufacturing, it is also used in logistics and supply chain, service related industries, healthcare, software development, product development, and administrative and office processes. Value stream mapping is a lean manufacturing technique used to analyze and design the flow of materials and information required to bring a product or service to a consumer. At Toyota, where the technique originated, it is known as “material and information flow mapping”. It can be applied to nearly any value chain. But how can you use this in your team?
The easiest way to do this is to grab some flip-chart papers and tape them on the wall, then divide the space in equal intervals, each interval represents a day of the iteration. Draw a line on the Y axis, this line should be on the position Y=0. If they are doing any activity that will bring value to the customer, tell to each member to draw a line on top of the Y axis line. On the other hand,draw a line under the Y axis line, if they are waiting or blocked by something. They need to do this activity everyday in order to to track all different activities inside the team. Do not forget to write notes when people are blocked or in IDLE; these notes are important to be discussed in the retrospective. The possible result can be something as the picture above seen above.
I guarantee you that you will have plenty of data for your retrospective at the end of the iteration. I tried this couple of times and I was surprised how many issues we find out, how many dependencies and blockers we had and so on. Having this information available will help the team to decide how and where they can improve.
P.S. On the picture, you can see different member roles. I know the setup is not perfect but it was what we could do at that time :) So, if you want to comment on the blog, try to ignore “non- optimal team setup”, instead focus on the activity.
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Value Stream Mapping a tool to help Systems Thinking
Hi guys, in this post I want to share with you a nice story that happened several months ago with one of my teams. At that time I had a team that was making the first steps towards Agile. They were a fantastic team, really eager to learn but still with the “old waterfall” mentality. They had a typical approach where the developers did development work and the testers – testing, not really a truly Agile team. I believe this is a common problem for teams that are switching to Agile: seeing only a small picture, they are not able to see the entire system. I believe they lacked “System Thinking”. But what is “System Thinking”?
Shortly explained, “System Thinking” is the ability to see the “big picture” and not to be focused on just a small part of your job. For a better explanation, I will use as an example my former team to demonstrate my ideas. In that particular team the work was arranged so that the developers had a set of User stories to work on. A finished User story was passed over to the testers for testing. The problem was that although for the developers these stories were quite simple to implement, they were quite challenging for testing because of several compatibility issues that required full allocation of testing resources. When developers ran out of User stories they were asking the Product Owner for more stories to work on. However, the PO acted rationally and did not give them any new stories until the team delivered everything to the iteration backlog. It was obvious that the team needed some help to visualize everything that was happening. How to help the team?
Clearly, the developers had their best intentions in mind: they ran out of work, therefore, they asked for more tasks. However, because of their lack of “System Thinking” they did not understand that more work for them would mean more pressure on the testing resources that were already fully allocated and, ultimately, an outcome of a poorer quality of the team effort. Apparently, the developers needed to understand that it was not anymore a matter of “us and them” because their job is accomplished when a customer gets the product, and the product would be ready when the team would act as a single unit. I have discussed this issue with some of my colleagues and they gave me a good idea: in next iteration to use Value Stream Mapping (VSM) for observing how the system behaved. This tool is a great instrument to identify different aspects of a system. If you want to use it you need to take some time to explain this tool to your team. From my experience not many people apply this in software development. VSM can be a fantastic tool to be used at retrospectives, but this could be explained in another post ;). Let´s see what happened at the iteration retrospective (an iteration where VSM was used).
By that time, the team was already familiar with the VSM and they were quite impressed with the amount of information we collected using it. Having looked at different VSMs (we created one for each different User story), it was not long before the team could see that bringing more User stories to the iteration would not translate into higher output because the testers were already fully loaded, therefore, producing more code would only mean that the testers would not be able to deliver everything on time. The team started appreciating more “System Thinking” and not just think anymore in terms of their separate “boxes”. After some discussions, the developers decided that in the folllowing iteration they would help the testers with all the testing activities to deliver more User stories as a team. In the following iteration the developers and the testers worked more as a team and the output of the joint effort of the team was indeed of a higher quality and volume.
Do you think this is something to consider when you work with your teams? What are your ideas on the topic?
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
What metrics should we use in an Agile project?
Hi guys, this week I started to read a book that is part of a reading list for the CSP exam. “Extreme Programming - Installed” and I found an interesting chapter about a topic that me and my colleagues were struggling with couple of weeks ago - “What metrics should we use in order to see how the project is progressing? ” Let´s take a look into it…
Ron Jeffries, Ann Anderson and Chet Hendrickson said there are mainly six kinds of metrics that is useful to play attention to in our projects: Resources, Scope, Quality, Time, Tracking and Reporting Scope, Tracking and Reporting Quality. So let´s take a look at each of these metrics.
Resources
Authors of the book defend that we should always keep a track on key resources - planned versus actual. These are number of developers, testers, customers assigned to a project and number of computers in a development, test and production.
Scope
Number of stories over time: how many stories exist, and how many of these are actually accomplished. We can also see how many stories were initially planned vs stories that we have on the backlog at the moment. This metric can give us an idea whether a product owner adds lot of stories or whether he sticks to the initial release scope.
Quality
Here, a simple graphic can be used to show how many automated test cases were run and how many of these were successful.
Time
The core is to track the results of each released plan and discuss the outcome and impact on the project when any functionality was added or removed.
Tracking and Reporting Scope
There are two main metrics: Iteration and Release burndown. The iteration burndown chart helps a team to track the iteration work (estimated vs done).
To track how the release is progressing we can use a graphic presented below. The red bar shows the stories that need to be implemented, green bar demonstrates the ones that were already achieved and the yellow ones the stories that were added to the product backlog.
This website serves as a source to a picture displayed above blog You can find more information how to “Read a Release Burndown Chart”.
Tracking and Report Quality
This part describes three interesting metrics. According to the authors, the first metric, that demonstrates the percentage of unit test that passed on an iteration rate, should be available. The number of successful tests tell how well a team is doing. Please, do not take me wrong, this does not mean that teams should not care about having all tests green during the iteration. You should always aim to have it as “green” as possible, but tracking it on iteration level is a good way to see how the team is doing on a release basis. Here you can find more background information to support this statement.
The second metric applies the same thought as mentioned above. However, this time it serves for acceptance and integration tests. Perhaps, in this case, it makes sense to separate the test by product area in order to see which of the product areas are more complicated. Below you can find a report for acceptance testing during an iteration.
Finally, as a last metric, a comparison matrix - test cases vs date can be used. This would show us which test cases failed and when did it happen. This would allow us to identify any trend that could emerge from there.
Do you think there is anything missing? Please feel free to comment.
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Is there any demand for “Agile Localization”?
Hi guys, this week I want to tell you what I have been up to for the past couple of weeks. I have written about it as it is always easier to see new ideas in a better light once they are written down. The purpose of this particular post is to invite you to a discussion about Agile Localization.
I have previously mentioned that I started with Agile some years ago, around 2007. Few years onwards while working for one of my previous employers I became responsible for improving the localization process for several products. At the time the localization for those products was done the traditional way - at the end of the product development process towards the end of the project. My role here was to change the traditional approach in-line with the Agile approach so that the product deliverables of each iteration would be localized. The initiative was a success and we were able to have product deliverables of each iteration localized in 87 different languages. After some years of working with Agile I decided to share all the knowledge I acquired during those years with other Agile developers out there, so I started the “Agile Localization” project.
I started writing a book on the subject thinking that it would be something I do in my spare time, but feedback I received from several friends and colleagues made me believe that my interest in Agile localization could lead to something more than just a book. Such as, a consultant might consider writing a book in order to have a successful career in consultancy. Together with two other colleagues we started a consulting company “Oikosofy”. The website mentions several innovation and Agile services that we offer, but there isn’t a mention of Agile localization there.
However, I think Oikosofy could offer Agile localization as a service to localization vendors to be offered to their customers. At least this is what I had in mind when I had a “sales call” from one of the vendors. But it seems the guy did not understand me, rather, as one of my business partners puts it: the problem is not with the listener but with the messenger. I believe, I did not explain myself well enough. So, I take this opportunity to explain my idea in order to see how you like it. Let’s say in this post I present my MVP(Minimal Viable Product) and I would like your opinion on whether there is a demand for this service out there.
The idea behind this service is to help companies sync their localization with their Agile development, so that the deliverables for each iteration would be localized. Of course, to make this possible a team must be already working in Agile and if they are not working in Agile yet, they can always contact us for help with the transition to Agile :). But coming back to the topic, this would be a service designed for teams that are working already in Agile yet still treat localization as something to be done outside the Agile process, at the end of the entire product development process. So our role would be to coach the team while working together with them and helping them adopt Agile localization practices so that they could have their product deliverables localised for each iteration.
This service would be offered as a partnership with the localization vendors who would take care of the localization of the product and we would be working together with the customer changing their way of doing localization. This would help the localization vendors because it would improve their collaboration with the customers taking it to a new level. Instead of receiving a huge amount of strings at the end of a development project they would be able to deliver small batches of translated strings for each iteration. This would be also beneficial for the customer because it would allow the customer to have the deliverables of each iteration in all the languages they require. Another advantage here is that the feedback loop would be scaled down, too, which means the customer together with the localization vendor can timely fix any problems with the localization thus improving the quality of the product and reducing its time to market.
So this would be one of the Oikosofy services in a nutshell - Agile Localization :). This is my idea of how Agile localisation could be developed into a service and I would greatly appreciate your feedback. Do you think there is a need for such service? Do you think Localization deserves to be a special service for Agile development, what would be pros and cons of it?
Thank you so much for your most valuable input that will help us a lot in developing further the Agile community!
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Constellation - A Good Exercise to “Set the Stage” At Your Retrospectives
Hi guys, this week I offer you a small exercise that can be used at your retrospectives, specifically, in the “Set the stage” part. There are many different exercises out there that can be used to start a retrospective, but I particularly like this one. I learned it a few months ago in Lyssa Adkin’s workshop in Stockholm (Agile Coaching Teams).This is a great exercise for people who do not like or do not feel comfortable sharing openly their opinion/feelings, at least in the beginning of the project when they still do not completely trust everyone.
We begin a retrospective with a welcome to the team members and with setting an affirmative goal for the session and this is where the “Constellation” exercise can be used. Like I have already said, due to the cultural backgrounds or the personality of team members, answering some questions can be difficult for some, but this exercise can help, because people do not need to speak in order to answer questions. He-he, now you might start wondering, “How could it be possible to answer questions in a team meeting without speaking”? Here is how we can do that…
Start with making an open space, move tables and chairs around, if needed. Put an object on the floor and explain to the team that this object is the center of the Universe and kindly ask them to form a circle around it. Explain to them that you will read some statements, and while you are reading the statements you would like them to move closer to or farther away from the “Universe” depending on how true the statement is in regards to them. So, if they really agree with the statement they should move as close as possible to the “center of the Universe”; if they do not agree with the statement, they should step back away from the center. Once you read a question, let the team observe the “system”, as Lyssa said, “Let the system reveal itself”.
You can use any topic you wish for this exercise, e.g., “How mature is our continuous integration process?”, “How mature is our automated testing process?”, etc. Just choose a topic and ask several questions related to that topic and let them see where they stand. Like I said, they do not need to give verbal answers at all, they answer with the movements by showing their position in the “system”. You could do several questions until you feel a good vibe from the team. To benefit fully from this exercise, you could ask the team in the end: “Where were you surprised with the shape?” and let them talk to each other a bit.
As a next step, you can, for example, ask the guys to form small groups of no more than three people each and ask each group to write down what they think would be the most important issue to improve. Of these issues you could then routinely select the most urgent issues to be improved in the next iteration. After that just agree with the team who will be responsible for what and close the retrospective.
So what do you think about this? It was useful? Leave me your comments.
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
How large stories can impact learning
Hi guys, this week I got inspiration for the post from a conversation that I had with one of my colleagues. I was explaining him the book that I read during my holidays - “Drive“. We went through many topics, but the one we discussed most was about Casual Friday, let me explain what it is.
In case you are not familiar with the term, you can think of it as a relaxed work day, the day when people are already in anticipation of the forthcoming weekend :). In the context of our discussion this pertained to that specific time that Google made popular with its employees: when they can use their time to do whatever they want, of course, within the company activities, but not necessarily related to their on-going projects.
The conversation continued for some time when he suddenly said that he cannot really do that, he does not have time to try this Casual Friday. He then explained that each their iteration takes two weeks, so if he starts using a day per week off the project they will have only eight days left and then they cannot deliver much for that iteration. At first, I could not understand him, so I decided to dig into it…
I asked him, “How come you cannot deliver anything in eight days? How long do you take to finish a story?” However, when he told me that each story usually takes six to seven days, I understood their problem. Of course, if they take seven days to deliver a story and if something happens, say a small delay, it would easily take them the whole iteration to deliver that one story, but they will not have any time for Casual Fridays.
In my humble opinion, they are just accepting too large stories. It would make sense for them to break these large stories into smaller units so that they could have more deliverables at the end of the iteration. Then I suggested that he tries an experiment: they could start creating smaller stories, say two-day stories, and they could see how many stories they would accomplish within the iteration. If everything goes well, they could deliver up to four stories per iteration and still have their Casual Friday.
I cannot promise that this would immediately solve their problems and allow them to have their Casual Friday, but I think they might be one step closer to it, because I truly believe that smaller stories are much better than the large ones.
This was just one example that demonstrated how large stories can have a negative impact on the development work. Here you can find more examples that explain why smaller stories are better for your development process.
What is your opinion about it?
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Goals trap!!! Be careful when your boss establish performance goals…
Hi guys, 2013 is here now, so first of all, I would like to take this opportunity to wish you all a successful New Year! I hope you had a relaxing time with your families and friends. During my Christmas holidays I read a great book - “Drive”. It made me think about what really motivates us. Part of the book talks about goal setting, which I think is a perfect topic for my first post in 2013. As it is the beginning of the year, I am pretty sure that soon most of us will have this “popular” meeting with the management to define our goals for the next six months. But is this really a good thing? Let’s dig a bit more into it…
How many of you heard that goals must be SMART? Do you actually think it is a good definition for goals? SMART stands for Specific, Measurable, Achievable, Realistic and Time-scaled. An example of a Specific goal for a company could be increasing the market share, as compared to a rather general goal of becoming more profitable. In order to see if an objective was achieved, we must make it Measurable by attaching a number to it, for example, to increase the market share by 3%. Objectives must be Achievable, which means that the company capabilities and the market environment should allow them to come true. Realistic means that objectives must be within the company’s reach, to expect an employee to become next Freddy Mercury might be a bit too ambitious :). The last one, Time-scaled, means that an objective must be attached to a time-frame, for example, in 12 months you will sit down with your boss again and see if you reached your targets. Are you familiar with this definition? Do you agree with this approach? Let’s see what some studies proved regarding this topic.
According to the studies discussed in the “Drive”, goals tend to narrow our focus. This does not sound too bad, right? After all, it is good to be focused in order to stay concentrated on a specific task and not get distracted by secondary aspects. However, in reality this is good only for activities that use the left part of the brain, i.e. for simple tasks that do not require creativity. But, as Daniel warns in his book, for complex and conceptual tasks giving a specific and measurable objective can blinker the wide-ranging thinking that is necessary to come up with an innovative solution. For example, if someone has a target to increase the revenue by 5%, they will draw a plan to achieve a 5% growth and no more. Consider that if they did not have that specific growth number, most probably they would think of many different ways of achieving growth, and most probably they would increase the revenue by more than 5%.
Another problem with specific and measurable goals, in my opinion, is that reaching them becomes the only thing that matters. Some people would prefer shortcuts to get there, even if it means making ethical compromises. On a larger scale, this may cause systematic problems for the organization: unethical behavior, increased risk taking, cooperation between the teams may deteriorate because it is not that unusual that the teams get conflicting goals that might be the source of inter team tension, and last but not least, general motivation might decline.
“Give a manager a target and he will do everything to achieve it. Even if he has to destroy the company in the process” by W. Edwards Deming
Personal goals that people set for achieving mastery are usually healthy. But goals imposed by others, such as sales targets, quarterly returns, standardized test scores, etc. can, at times, have detrimental side effects. Therefore, you must be careful when you set goals in your organization. Please, do not take me wrong, I believe we must have a direction, a company goal, in order to know where we are heading. But I really am skeptical about the SMART model. What do you think about this model? Let me know your opinion :)
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Agile Localization - Outplay the competition, enter new markets and grow Internationally
Hi guys! This will be my last post this year due to Christmas season. I would like to take this opportunity to present my new personal project. Together with my two colleagues, Vasco and Wim, we are going to write a book about Agile and localization. The general overview of the book can be found here.
The people who know me understand that I am very passionate about Agile. So, we would like to take an Agile approach in writing our book. It will remain to see if this experiment would be successful, but since I have this idea, I would like to try it out. Put simply, writing a book is a creative process much like developing software - at the end of the process there are potential customers that would buy the final product. Therefore, why shouldn’t we write a book applying the methodology we use to develop a software product?
Our idea is simple. Like in Agile software development, we are planning to write the book in iterations, which means that we would not follow the traditional pattern: first write the whole book, then publish it and only then get the feedback. Instead, by the end of each such writing iteration we want to release the increment of the book we wrote and get the feedback from the public. Like in Agile software development, the feedback will be integrated into the book to improve it. Every time before starting a new chapter, we will communicate its topic to our audience and invite our followers to a discussion about what they think is important to include in the book. Naturally, the book will have the main story, but the idea is to adapt the book to our “readers´ needs”.
The localization of the book will also be part of this incremental process. To have the book localized for a particular market, we would not need to wait for weeks until the product would be released in English first. Instead, as soon as the iteration is finished, the released increment of the book will see the light in English and in some other languages, too. If we really believe in this concept, there isn’t a better way to prove it than to apply it in our own book.
We are starting this project in January, and we would highly appreciate all the feedback from you, guys. If you are interested in our project, let us know! Let’s use this blog for communicating and collecting your thoughts about the book. Another thing, we would highly appreciate if you could tell us how much you are prepared to pay for the final product – the finished book. This would give us an idea about the price range for price-tagging the book, please, leave your comments here. Another way to leave your comments will be using our NPS system. Some weeks ago I wrote about NPS, you can find the post here. Before we start releasing the first chapters we will have in place a system where you can leave your NPS score.
There are a number of other issues that we still have to solve, but being truly Agile means that we will be adapting along the way and tackling issues as they arise.
Now, the only thing missing is your initial feedback. What do you think about all this, guys? Do you think this could be a cool project to be part of? Would you like to take part of this project?
Look forward to your comments ;)
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
NPS a great way to help the PO to structure the product backlog - Part II
Hi guys, in my last post I explained what NPS means. I finished the post explaining the benefits of this concept. In this post I will explain how NPS can be used as a great way to collect user feedback in a structured way identifying priorities that should be taking into account for next interactions/releases. I will explain this by giving an example of a company where I used to work.
Several years ago I worked in a company that used NPS on daily basis. They used NPS everywhere, in my opinion it was used too much but that is how they worked. They used NPS to compare product performance between organizations; they used NPS to measure employees´ performance and at last they used NPS to help product owners to prioritize and build product backlogs - this is what I want to talk about in this post.
All customers that used products could answer the question: “How likely is it that you would recommend our product to a friend or a colleague?”. This question could be found under the “feedback” section inside of the product. When the user answered the question he or she would send the score and respective comments justifying his/her answer to a server where all scores with the respective comments were collected.
To analyse all these comments and scores, a team was created. Their responsibility was mainly to collect, analyse and cluster all different feedback. This feedback was sent once a week to all product owners involved in the product development. This feedback was extremely valuable since it would help the Product Owner to create a better product in future based on real wishes from the customers. The product owner could use this either to review his/her previous assumptions of what could be a good product, or to tackle emergent problems that appeared in each release. For example the sign would be if there were dozens of customers complaining about the same issues.The product owner would need to act. These issues should be tackled in next iteration in order to correct customer unhappiness. Clearly these matters had the highest priority in the product backlog because they had a direct impact on the customer.
All this feedback was critically important during the whole development phase but especially before the official release, when the product was in Beta stage. We used this time to collect extremely valuable feedback from customers in order to improve the product for the official release. At this point the PO was looking at feedback on a daily basis. This would allow the team to be able to change the most critical issues before the product was released resulting in a better product with a better customer satisfaction.
NPS is still part of the company´s product development. Even though I do not work there anymore, I truly believe they still use all customer feedback provided by NPS to improve their products.
To conclude this post, imagine this: You together with several other customers detect and report a problem. Two weeks later in the next iteration release you have the problem solved. The company was able to listen to you and correct your problem. In two weeks time!!! What would you think about the company that can listen and attend your wishes in two weeks time? It would be amazing, right? Do not worry, I believe this is the future :)
This was another topic that I wanted to share with you guys. I truly believe NPS can help companies or Product Owner to improve their own products and understand how well they are doing compared to other companies that use NPS as well. What is your opinion after reading this post?
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
D5 Creation