Recently, I spoke with an insurance company’s Director of Application Development who struggled with internal and external misalignment. She said her department is constantly asked to create new software, but her team struggles to collaborate with internal business stakeholders on how the software should work. She also mentioned that they are typically given unclear and conflicting requirements, and both her team and her customers are often not on the same page.
To help her team get back on track, we discussed some of the strategies that we use at AgileThought to help clarify the vision for new software. Here are some of the processes, tools and mindsets we use for developing new software products—and why we use them.
When you create new software, it’s important to think of it as a new software product. That may seem obvious, but in enterprise software development today, the word “project” is used far more often than “product” to describe new software. This is a critical mindset shift because it defines what you’re trying to achieve.
The word “project” implies a work structure with a beginning, end and temporary nature. The word “product” implies that we’re creating something tangible and with a useful life—which is exactly what we are doing when we bring new software into existence. Because it’s long term instead of temporary, it’s critical to collaborate, document your hypothesis and assumptions, and consider the value a new product is going to bring to your customers.
Tools like the Opportunity Canvas, the Lean Canvas, and the Business Model Canvas are simple-yet-complete one-pagers that can help facilitate discussions about product—not project—strategy. When creating a new product, we strongly recommend creating one of these canvases in a highly collaborative way with your team. You might be surprised with the results and think of new, creative features!
As mentioned earlier, many companies struggle with internal and external alignment. To combat this, you need a measurable guide, or product development “North Star,” to guide decision-making for all product development. One such solution: the objectives and key results (OKR) framework.
The OKR framework—which defines a goal to achieve (objective) and up to three key results that measure progress toward the goal—encourages teams to revisit goals more frequently and aligns the entire organization from top to bottom. Establishing OKRs, or implementing another measurable guide, sets the foundation for your product development initiative; without it, there will be misunderstanding about the common goal.
Requirements are not berries to be picked from a bush. They cannot simply be “gathered.” If that were the case, we could have our business customers fill out a form, or perhaps even use voice technology like Amazon Alexa to interview and gather requirements from our business customers.
People often have their own personal visions for what they need, then describe this to software product teams—often in the form of the design of a solution or technology. I’ve even seen business customers state what they need in the form of a SQL statement! However, this isn’t useful to a software product team. We still don’t understand the problem, and we aren’t allowed to do our job, which is to design a useful product.
The next time you are invited to run or participate in a “requirements gathering session,” challenge yourself and the team to truly get to the root of the problem, so you can design and build an incredible software product that goes beyond requirements.
Are you building a departmental app that solves a niche problem, has few system integrations and serves a limited number of personas? Or are you building an enterprise-wide app that serves an audience of thousands around the globe?
If you’re on the simpler end of the scale, you may be able to build a vision and personas in a week. If you’re on the more complex end, you may need to spend a few months building an understanding of your audience in order to build a product that serves a diverse base. If you find yourself needing more than several weeks for a single, large-scale product, perhaps step back and look at this through the lens of a larger scale platform, or several different apps, to serve different global audiences. It’s critically important to avoid “analysis paralysis,” where you overthink the details of a potential solution and miss opportunities to define the problem space and capitalize on the market.
If you call the people who are going to be using the new product “users,” do you really understand who you are building for? Yet, this is the term that most people use. It’s easy, but it’s lazy. Product strategy, features and functions are heavily influenced by deeply understanding and empathizing with the people using the product—therefore, we recommend creating personas to influence product design.
Personas define the essence of real people who will use the product. Personas define what a person values, how they behave, what they need, how they live, and what goals, interests and desires they pursue. Personas are most often built from data collection on real people, which helps avoid product design being overly influenced by the product development team. Think differently—if you find yourself still using the term “users,” consider that the people using your application are real people, with real emotions and needs that you can learn from.
Development teams often want to jump right into writing code—after all, that’s their passion and what they get paid for. But, before jumping right in, it’s crucial to get them involved in the discovery of understanding the problem. Encourage them to listen to customers’ viewpoints, understand and participate in persona building, and to get involved in the product design.
One great tool for understanding how people will interact with the product—and a tool that is very helpful for creating a technical design—is a customer journey map. A customer journey map is a visualization that tells the story of how customers experience your product from beginning to end. It’s a highly visual tool that will inspire your development team to think about the product’s technical design in a new, unique way than they would otherwise think of. This pays off in spades because it produces technical design that fits the problem space more effectively, and gains buy-in from the product development team that they aren’t just responding to an order; instead, they are truly part of the product lifecycle and are able to influence and understand product decisions.
Pointing a product development team in the right direction with a clear vision, a deep understanding of the personas and problems, and collaborative methods for designing product experiences is critical for modern enterprise software product development efforts, and also serves as the foundation of a digital transformation. If you’re unsure where to start, or if you need help bringing your product to life, contact AgileThought to learn how our product strategy experts can help you build a successful software product, the right way.
Contact us to share the challenges you’re facing and learn more about the solutions we offer to help you achieve your goals. Our job is to solve your problems with expertly crafted software solutions and real world training.
For a better experience on the web, please upgrade to a modern browser.