In today’s hyper-competitive landscape, where new products are flooding the market every day, standing out amongst competition is more important than ever — not just when you introduce a product for the first time — but consistently over its lifetime. Otherwise, your product becomes yesterday’s news. Managing and then taking action on the mounds of feedback can be yet another challenge. In this post, we will learn why regularly checking-in with your product and managing it through the chaos can lead to continued product success and better feedback management.
When we visit the doctor, one of the first things the physician does, no matter the appointment’s primary objective, is check your vital signs: blood pressure, heart rate, pulse rate and temperature — all of these tell the current state of your health.
The results from this kind of check-in can help the physician adjust their next steps quickly — an especially good thing in the event that something during the checkup doesn’t register as normal or healthy.
Product development is no different. The same thorough approach should be applied when assessing how a product is performing. If you take the general idea of regularly checking the vital signs of your product — performance, market fit, end-user experience and use cases — your product will always be in the prime of its lifecycle. When applying a real-time product feedback method to product development, many fall short. Lots of factors can be the culprit here, including:
- Not enough data is being collected on the product.
- Too much data is being collected on the product.
- The data that needs to be collected is not being collected at the optimal time.
- Collecting the right data at the right time is too expensive and/or too time-consuming.
- There is a lack of knowledge in regards to how to collect data at all.
In this post, we will tie in the aspect we learned in Build Better Products With Intelligent Product Feedback, and discuss them in more detail. At the end of this short article, you will learn the basis of an agile development process and why applying the method to your product development process is an absolute must, especially in today’s business landscape.
“Product testing has been around as long as there has been capitalism, but in the big data era, companies are now able to test and understand their technology products in a way that was not possible ten, or even five years ago,” says contributor Dan Woods of Forbes.
Collecting real-time data can be a curse and a blessing. To make sense of the data deluge, you must know to manage it all and then learn how to prioritize it alongside product roadmaps, your objectives of collecting the feedback in real-time, and the company’s goals. For this, we recommend applying an agile development product process.
Over time, you will collect so much data on your product that it hits you from all angles, and knowing what to do with it all can seem like a constant struggle. If you apply a repeatable process to collecting and managing the feedback, you can then begin to prioritize and act on what feedback is going to be the most valuable to your team and product.
Key Agile Development Principles to Know Before You Start
“Product owners who don’t use agile requirements get caught up with spec’ing out every detail to deliver the right software (then cross their fingers hoping they’ve spec’ed out the right things). Agile requirements, on the other hand, depend on a shared understanding of the customer that is shared between the product owner, designer, and the development team.” – Atlassian, a company that is popular for its project management software products catered toward the agile process.
When defined, the term “agile” simply refers to managing IT developments and projects. When this method is applied to an organization and its IT/Product teams, it adheres to that company’s values; not every agile process is the same, but the fundamental principles are. Deemed the most valuable agile player in the UK and prominent author on the topic of agile, Kelly Waters uses ten key principles when applying the method.
Active user involvement is imperative
Insisting that users be directly involved in projects during the early development stages, while ideal, is not always possible. Having senior and experienced users involved throughout the process is best practice. From clear communication set at the outset to prioritizing users and markets needs, developers are then held accountable and have a high degree of transparency throughout the process.
The team must be empowered to make decisions
Building off of the first principle (active user involvement), this principle ensures that all key stakeholders are involved in making core decisions. Allowing all team members to have skin in the game during this process gives each member the responsibility to deliver as well as the power to say no to anything that can potentially derail them from focusing what is needed during that project’s sprint cycle (more on sprint cycles later in this post).
To keep the team closely aligned with this principle, they must agree on and fully understand all the project’s requirements at the very beginning for the process to be successful. Without everyone starting off on the same page, no one is being set up for success.
“…This is a key principle for me. It ensures the buy-in and commitment from the entire project team from the outset; something that later pays dividends,” says Waters. “When challenges arise throughout the project, the team feels a real sense of ownership.”
Requirements evolve but the timescale is fixed
Typically, when starting out a project we tend to lay it all out on the table, so to speak; all of the requirements, scope, timelines, responsibilities, and deliverables knowing very well that any of these variables may — and likely will — change during the project. With the agile process, while requirements may change and evolve, the timescales remain fixed, which decreases the chances of scope creep or bloated scopes — throwing developers and product managers off course quickly.
With agile, the process accepts that things change; however, to factor in a new requirement perhaps brought to the service through early user testing, another aspect of the project must be taken off the scope as not to disrupt the deliverables’ timing. This allows for the project to flow with the ebbs of change but allows enough room for that change to be factored in. Product owners can then stay hyper-focused on evolving in the right direction, and as efficiently as possible.
Capture requirements at a high level; lightweight and visual
“Agile requirements are ideally visual and should be barely sufficient, i.e. the absolute minimum required to enable development and testing to proceed with reasonable efficiency,” says Waters. “The rationale for this is to [minimize] the time spent on anything that doesn’t actually form part of the end product.”
A flexible process, yes, but one that is rooted in a high level of discipline, the agile process was born and bred with staying lean in mind. Requirements for the project’s success should be captured and integrated at a high level from the very beginning as to avoid unnecessary roadblocks or derailments. This information is gathered during workshops or white-boarding sessions, or a time early on where the team has come together to agree on action items and key deliverables. Visually speaking, the information gathered during this stage could be a combination or one of the following elements:
- Mood boards
No matter what visual representation you choose, it should contain information on the look and feel of the solution and how an end-user is projected to interact with the product. Within many agile teams, this element takes the form of a “user story” or a few sentences that describe the user’s experience with the product from the user’s perspective.
An example of a user story: “As a user, I can download a PDF report on all data activity in a certain amount of time and have that data be visually displayed so I can easily share that high-level story to my executive team.”
Develop small, incremental releases and iterate
Mostly, don’t bite off more than you can chew. As cliche as the saying is, it is based on truth. By having projects sliced and diced into small bite-sized pieces, it allows developers and product managers to hone in on that small piece and execute on it successfully before moving onto the next. If this approach is applied to each piece of the project, it contributes to greater efficiency, higher costs savings due to fewer mistakes, and an overall higher quality product.
It goes without saying, but for this method to become a reality and one that is expected from project-to-project each feature that is being broken down into smaller bite-sized pieces, each and every feature must be fully developed before moving onto the next one. This is where prioritization plays a critical factor.
Focus on frequent delivery of products
It’s no longer breaking news to say that technology moves quickly and we must keep pace — if not set the pace. Yet, staying ahead of all the changes can be maddening, to say the least. Determine a list of features and set a schedule of incremental deliverables to set expectations with your team and end-users, but also keep your projects doable in a tight turnaround environment where quality will not be sacrificed.
Break your project sprints into a timetable that makes sense to your organization. Some say two weeks is ample time, while others say 30 days. Take a look at your company’s goals and how your department and how each project contributes to that end goal. Then stand back to holistically break it down into sprint cycles that meet the needs and size of your team, priorities, and objectives.
Complete each feature before moving to the next
The rule of thumb is that all features committed to the sprint cycle should be completed by the end of the cycle. And complete here means totally and absolutely complete.
Having a gauge on how many things are completed within a sprint, you and your team can have a complete and accurate progress perspective. This allows a high level of transparency into every project your team is committed to.
“Completed” features or features are considered “Done” when they meet the following criteria:
- Each feature is fully developed
- Each feature is fully developed
- Each feature is fully tested
- Each feature of fully styled
- Each feature is accepted and QA’d by the product owner
Apply the 80/20 rule
“In agile development, we should try to apply the 80/20 rule, seeking to focus on the important 20 percent of effort that gets the majority of the results,” says Waters.
The rule, rooted in the law of the vital few, and more formally known as the Pareto principle, is based on the fact that many things are not distributed evenly. It often results, when applied correctly, in higher productivity. Originally applied to the wealth distribution of Italy in the early 1900s, this rule has become paramount in business to help prioritize and manage work. When applying yourself to a feature development consider keeping this rule top-of-mind: Focus on the few, larger items that will generate the most significant results.
Testing is integrated throughout the project lifecycle — test early and often
We don’t have to go into the details about why testing is important. As product managers and developers, testing is par for the course. This usually happens during smoke testing or the Q&A process. What agile strongly encourages teams to do is to build in small as you go tests into the process that can be repeated easily. Making these small tests part of the build allows teams to easily and confidently say if all features are working as they should or see what is not quite there yet. The agile process recommends these size tests occur daily.
A collaborative and cooperative approach between all stakeholders is essential
An agile approach is based on the effort of a team, and without establishing a team mentality from the get-go, the relay of the process will not work together and will collapse. When starting this process for the first time and as it matures in your organization to meet the needs and uniqueness of your product lifecycle, align the method to the values of collaboration and cooperation. This applies not only to those working with the method but any key stakeholder that is part of the project as a whole — and this could be outside of your department. The success of the method solely depends on solid and consistent cooperation and collaboration.
“Agile development can be a very exciting and invigorating approach, although some projects suit agile more than others,” says Waters. “The collaboration and visibility can provide a much richer and more rewarding experience for teams to develop great software products.”