When taking new ideas to market, avoiding risk could be your biggest risk of all

So, you have a new idea for a digital product. Providing the team with an airtight product requirements document and process checklist might seem like a good way to mitigate risk — but with this approach, the best-case scenario is getting exactly what you asked for.

In being so prescriptive you’ve forfeited the opportunity to make your product better than you ever imagined. And, if your assumed solution is wrong, you could strike out completely (i.e., you’ve missed the mark in solving a real problem in a way that your customer will love and depend on.)

Gitwit’s product team is a strong proponent of intentional exploration, moments of excess, and even constructive chaos, knowing that these are often the game-changing moments of the product design and development process on the path to creating innovative products.

Instead of fixating on risk management, as teams often do, the key is to identify what things will actually benefit from risk-taking and which ones won’t. Gitwit’s Head of UX Strategy, Ashley Roberts shares her thoughts on when being bold pays off and how we architect these moments to go bolder into every product design/development process we help craft

When we talk about having a calculated, risk-taking approach to product development, what do we mean?

Clients bring us in for several reasons. They’re either building a brand new product/business, entering a new area (new target users, new market/industry, new application of existing technology), or needing help energizing established teams and products. 

In each of these instances, they are looking for us to help them do something new. Doing something new inherently means taking a risk. To pursue something new is to do something bold, so our responsibility is to help them create the most powerful, impactful version of this innovation. We’d be doing our clients a disservice if we looked only at the most obvious product concepts or processes to get there. Whether said explicitly or not, clients are coming to us in pursuit of a team that will push them beyond what they know to be possible. 

So, we should be open to taking risks at opportune points throughout the process, but how does your team plan for those moments?

Planning for boldness can take shape in a myriad of ways. We create room for boldness when we design brainstorms for concepts (our unique and unconventional processes), think about who is involved in brainstorming (using SMEs to sketch ideas, inviting end users), consider how quickly we create a prototype (sprint-based models), decide the order in which we build (build first, validate soon after), etc. 

Taking time to be bold doesn’t have to be a grand gesture. Let’s look at a recent example: We worked with a construction company to build a new application for foremen to manage site completion. Early on, we gathered inspiration for how the product should look and feel. We started by focusing on similar industries, such as construction applications, job site management, etc. 

However, we quickly realized that much of what was available in that industry needed to be more inspired. We speculated that we would be more successful looking at entirely unrelated verticals and companies, searching for novel connections and innovative solutions in unlikely places. We wrote out our user needs and asked, “What products are solving similar problems for completely unrelated users?”

We used Nanit, a baby sleep monitoring application, as a primary source of design inspiration as we built a product for construction site foremen. The unconventional decision to use tech designed specifically for new moms as inspiration for our product was a calculated risk that paid off. Our Nanit-inspired solution led to a truly unique approach to job site management. 

Creating moments that break open new opportunities sounds exciting, but budgets and deadlines are real considerations. How do you balance the tension between creativity and business constraints?

Being crystal clear about where you want to go makes everything else easier to plan for. This is why our first step in most engagements is to help stakeholders align around a strong product vision (see Product Vision article). When we understand the ultimate objective we are all working toward,  we can help you determine which risks must be mitigated and which should be taken. From there, we develop project plans, timelines, and budgets that intentionally create these moments for boldness. 

Recent approaches that we've taken to create unexpected boldness:

• Build a working model first and test it immediately after.
  Why: We wanted to confirm that the product could and would function as we promised before we poured design resources into building an optimal user experience.
• Explore concepts first and test many ideas with customers.
  Why: We didn't want users to lead us to a predictable solution because they hadn't considered anything else. We could smoke out real issues and vet truly original ideas by offering bold alternatives.
• Move customer communication outside of the product. 
  Why: With a short timeline, we knew circumventing customer communication inside the application would save us weeks of development time. Plus, we saw an opportunity to drive users back to the application after their first visit. For the initial product launch, we communicated with users via text and required action inside the application.

Risks we’ve seen backfire:

• Building an MVP with all the bells and whistles and waiting until launch to test for the first time.
  Why: So much time and money was put into this release that we had no option but to succeed. It is easy for stakeholders to become disillusioned and disregard any negative feedback as ‘unreliable data.’ 

The takeaway: being bold is not synonymous with inflating your budget.  You can use the budget as a motivating constraint when planning for boldness.  In fact, being bold is sometimes the best way to maximize the impact of your dollar.

Okay, say someone is bought into the idea of strategic risk-taking. What should they look for in a team? And what makes Gitwit particularly skilled with this approach?

First, it’s helpful to know the signals of a team that is only thinking of risk mitigation. A risk-allergic product team might ask for things like requirements lists and product documentation before ever asking about a user problem and the business opportunity. If you are looking for a team that will push your ideas beyond what you currently know and believe possible, you want a team that first looks to understand problems and opportunities.

A few things come to mind when I think about why our team is successful at leveraging risk. 

• We are familiar with and confident in ambiguity—rapport, even—and aren’t easily rattled. We pride ourselves on being comfortable with the uncomfortable. We won’t rush to assumptions or solutions just to avoid the sometimes uneasy problem space because this is where the true breakthroughs happen.
• We bring expertise from industries outside your own. This makes it easier to draw connections and adapt ideas from other places (see: steal like an artist) to benefit you and your end users.
• Our team has a wide variety of skills, talents, and expertise, all dedicated to your product. This means we can adapt our plan to include the right people at the right time without losing momentum.

We have built a practice around running creative processes in a way that is tethered to reality. We aren’t throwing out the playbook when we decide to be bold and take risks; this is the playbook.

Building something new or wanting to bring new life to an existing product? Talk to the Gitwit product team about architecting a process to explore possibilities and build bolder technology.

‍