Product Design & Development

A Designer’s Toolkit for Developing the Right Software

In today’s tech industry, many development teams have been involved in projects where assumptions are made about customer or user needs. These assumptions might come from an executive, a stakeholder, or even tech and design leaders. Sometimes these assumptions work, but many times they are built without understanding the users’ needs – making the experience ineffective.

One well-known example about not understanding a user need was written by Jared Spool. A company had a $300 million dollar problem without anyone knowing. This company required registration upon checkout of their ecommerce website. Spool talked to users and found out they didn’t want to register with the website to make purchases. 

I’m not here to enter into a relationship. I just want to buy something.

Explained One Tester

Armed with this information, the team removed the registration requirement and made it optional for a user to sign in for purchases. This simple change generated an extra $15 million in sales in just the first month and $300 million annually. 

Strategic Impact

In our ever-changing world, validating that you are building software that is desirable, feasible, and viable is an essential part of business.

  • Desirable = What does the user need and why?
  • Feasible = What technology matches the project need and is accessible to the company?  
  • Viable = How will this application help business goals?

Desirability, feasibility, and viability are constantly evolving – rapidly. So, how do modern software teams build quality software effectively? By being aligned and focused on the problem, keeping things simple and iterative, and continuously learning together.

To produce quality applications, development teams must come to an agreement on the problem they are solving and continuously build, test, learn, and iterate together. All while keeping the end user in mind throughout the whole process. Without this foundation, the project is set up for inefficiency and waste. Here are a few strategies to help establish a baseline so your team frequently confirm what is being build does bring business, team, and user value. 

Team alignment on scope and focus

As a team, one of the first steps of a project is to frame the problem you are solving. The team must know “What” they are building but also “Why” it’s being built in the first place. This step sets up the range of solutions and is needed to make the project effective and sustainable. Breaking the conversation down to its simplest form helps the team understand the real needs.

Consider things like:

  • Our users are saying they need X, why is that?
  • When stakeholders are asking for X, what do they really mean? 
  • Is there a reason we’re using technology stack X? 

Defining the parameters of the project from the beginning helps refine scope, gives the team focus, and lays the foundation for team communication throughout the project.

Toolbox for Alignment

There are a few tools we can use to efficiently elicit this information. It’s important to understand what the benefit of each tool is:


Kick-off Meeting: The first project team meeting to align on problem statements and desired outcomes for the project.

Used for: Introductions, Understanding Project Requirements, Individual Roles and Responsibilities, Defining Problem Statements, Discussing Security Practices

(.5-1hrs Each)

Empathetic Interviews: Conversations with business leaders, users, and technologists that use open-ended questions to evoke specific experiences to uncover unacknowledged needs. Team can look for patterns on how questions are answered.

Used for: Understanding users perception, not usability.

(1-2hrs Each)

Personas/Archetypes: Data-driven insights about behaviors, attitudes, goals, and pain points to align the team on user experience priorities. 

Used for: Representing your target user(s). 

(1-6hrs Each)

Customer Journey Mapping: A visual representation of the process a person goes through to accomplish a task. 

Used for: Understanding the user flow to reduce friction when using the application. There could be different journeys based on user type.


  • Understanding the user intention, refines project scope to what is valuable immediately.
  • Up front discovery as a team leads to a better hypothesis of what is needed.
  • A team understanding user needs leads to better decisions by all team members.
  • Research helps a team understand where to build, not what to build.

Keep it simple – gather feedback and iterate

Once you have defined the parameters, it’s time to start solutioning or the “How” of the project. The Software Development team ideates a hypothesis for the project using knowledge gained from defining scope and focus.

Open-ended questions can help facilitate this collaboration:

  • What ideas fit the user needs, business goals, and technology for this project? 
  • What Security-by-Design principles or tools to leverage? 
  • What gives our users value from the beginning?
  • What is possible with the technology that we have available?

Once the team has aligned on a hypothesis, they will start building the easiest path from start to finish – often referred to as a Minimum Viable Product (MVP). Thanks to kick-off meetings, empathetic interviews, persona creation, and customer journey mapping, the team should be aligned on the project priorities. 

Successful teams can add value from the start and quickly deliver quality software by leveraging the user workflow exercise to plan what parts of the application. Once the simple path is mapped out, the team can begin an iterative process: 

00) Build something that adds depth to the application. 

01) Test updates with users. 

02) Demo the application with stakeholders.  

03) Make any updates that are needed. 

04) Repeat from 00.  

Building in small steps makes it easier for the team to be flexible when it comes to priorities, testing, gathering feedback and making changes. Gathering feedback and making iterations while you build will lead to less risk when the application is released.

Developer’s Toolbox for Iteration


Story Mapping: A method for arranging user stories to create a more holistic view of how they fit into the overall user experience. Sometimes referred to as a product roadmap. 

Used for: Outlining tasks needed to build a new product or a new feature for an existing product and arranging them into functional groups.


Agile: Iterative development methodology that delivers software to market (and value to clients) faster and with less headaches. 

Used for: Delivering secured software in small, consumable, production-ready increments. 

(30-60mins per interview)

User Testing: Interface and functions of a website, app, product, or service are tested by real users who perform specific tasks in realistic conditions. Example: Can our users get through the workflow without help? Are there sticking points? Is the language clear?

Used for: Information gathering about user experience to make application adjustments. 


  • Quality and security is built-in as the project is developed.
  • Feedback helps reduce risk of usability.
  • Value to the user, business, and the development team.

The team is always learning

Deeper Understanding for Company Leader

Because the team is consistently testing their app, their knowledge about users’ needs will become mature. Teams share this information with company leaders who can strategize, create vision, and make better informed product decisions.


Because the team is constantly thinking about the user, they notice they are making more objective decisions, which benefit the quality of the project. Teams develop a strong trust where ideas for solutions might come from any one of the members. For example a developer might have a great design solution and will feel comfortable discussing with the team. Not only does learning create quality output but it also creates a more fulfilling experience for your team members. Each role might overlap their responsibilities to educate, empathize and help build an effective application.


As the project evolves so will individual team members. Using this collaboration, Individual members learn more about the business, the users and technology making the employee even more valuable for their next project.

Toolbox for Learning

Paired Programming: Pairing up to work on development tasks leads to better code, diffusion of knowledge, transfer of skills and resiliency. 

Desire to Learn: Team shares articles, blog posts, podcasts, etc. and are always learning new things. 

Simple Discussions: Team is not afraid to ask questions or ask for help. Discussions with the team can clarify issues and bring forth a simple solution. 


  • Education provides value to companies, teams, and engineers.
  • Learning create more dynamic team members.
  • Psychological safety leads to better ideas and implementation.


Does your company align on scope and focus? Do your team practice quick iterations and make quality changes based on feedback? Do your employees educate each other and learn new things through challenging tasks? Whether we work as a strike team or consult client teams, Trility bakes strategic impact into our work.

If your team needs confirmation they are building the right thing, we can help figure out where you are at, where you want to go, and how to get there both strategically and tactically.

Product Design & Development

Assessing Viability of a Technology Initiative

As a technology leader, you’re responsible for assessing projects, making decisions that add value, and creating opportunities for your team to succeed. You often spend time overseeing more than one project or initiative and are required to focus on two or more of the following types of activities:

  • Building and refining product roadmap(s) to confirm that future work is valuable to the organization and your team. 
  • Reporting project updates to managers or stakeholders.
  • Educating yourself and your teams on tools or products that have evolved to ensure projects remain viable.
  • Understanding what applications and tools are being used, how they talk to one another, and if they are integrated in a secure way. This focus might be highlighted if:
    • Your organization acquired a new company.
    • Your organization was acquired.
    • You inherited a new team or project.
    • You are new to the organization. 
    • You are shifting left in your security journey.

These responsibilities often have a two-fold focus – customer value and the company’s bottom line. On top of managing multiple things with this split focus, you’re working in a rapidly evolving industry. You are constantly assessing high stakes and high opportunities. Decisions don’t seem to slow down. They only keep piling up. 

Decision-making made practical  

Some people feel excited, anxious, or have different emotions altogether when making important decisions. Those feelings are valid – identifying what matters and what doesn’t can be hard if where to start seems unclear. 

You can leverage the Assessment Framework to understand where you’re at, where you’ve come from, and where you’re going. A robust project evaluation ensures all context has been discussed and considered – increasing the odds of product or project health, security, and viability. 

Ideally, this process will provide you one of the following recommendations:

  1. Project is working well.
  2. Project is not working well, but it is correctable.
  3. Project is not working well, and is not recoverable in a way that makes business sense.

This framework was originally described by Matthew D Edwards in his article, Distill What You See Into Action.

Download the Assessment Framework to determine the health and business value of your initiative. For even more accurate results, include your team to consider and broaden your perspective. 

Making Your Assessment Actionable

If you desire an outside perspective for assessing the health of your project or initiative, reach out to Trility. Our teams can help by conducting the assessment and leading a discovery process, building out an actionable roadmap, and partnering on areas of work where your team may need to leverage future-state skills.

Product Design & Development

Distill What You See Into Action

On Monday morning, you receive a phone call from a Senior Partner in your company. A client of your company is preparing to go live with a new software system in sixty days. The Senior Partner, knowing you have extensive, successful experience delivering technology systems to the marketplace that meet or exceed functional expectations, are secure-by-design, delight customers, generate revenue, and increase brand value, wants confidence that everything will happen as planned and desired. You can name your price, but it doesn’t change the fact that you have three weeks to learn, assess, refine, and present observations and recommendations. You have no idea how deep the rabbit hole may go. After some back and forth in the conversation, you accept.

You’ve done this before. You know what to do. You have a battle-tested framework for assessing large volumes of data in short periods of time to determine planned versus actual deltas and risk+probability remediation plans. This framework that you’ve developed over the years and myriads of assessment/salvage operations helps you not only identify what, why, and when, but also what not. In other words, while you’ve found success making observations and recommendations, the real magic has been identifying what doesn’t matter, what doesn’t need to be addressed, and/or what can safely be ignored for now, and perhaps forever.

Identifying what does not matter is often harder than identifying what does.

The assessment framework you use for these types of engagements is structured to help you discover project health and corporate risk while eliminating noise. After all, folks pay you to figure out the state and health of their investment in short, thorough engagements. And what they expect is a concise list of observations and recommendations that guide immediate decisions leading to crystallized outcomes.

You know there will be one of three possible outcomes:

  • Outcome One: This project is working well. You may recommend some changes here and there to fine tune the performance, but overall, the effort is heading in a good direction and should render the desired outcomes according to the expected parameters.
  • Outcome Two: This project is not working well, but is correctable. You recommend a number of changes that will bring the project back into expected performance. You additionally recommend some key areas (health indicators) of the project to keep an eye on from today through end of project so they minimize the possibility of ending up here again.
  • Outcome Three: This project is not working well and is not recoverable in a manner that makes financial sense. Your recommendation will likely be to close the project down, perform a retrospective, and use the output to influence project structures and decisions in the future.

From experience, you also know that some projects classified as Outcome Two should really have been classified as Outcome Three. However, after reporting your results to the Senior Leadership team, they were not yet willing to accept the possibility of a sunk cost effort and instead chose to believe doubling down on the effort would pull it back into the green zone. (Where “doubling down” = “get more people, work harder, spend more money”.)

The Assessment Framework

For each category below, research and understand what exists, what doesn’t exist, in what state it exists, and what must, could, should, or will not be done accordingly.

01 Problem Statement

What problem does this organization need solved? Would you categorize this as a business, technical, security, compliance, team member efficacy, or client-driven problem? What is the known/perceived blast radius of this problem statement impact — the industry, your target market, your enterprise, or localized within an enterprise?

02 Desired Outcomes

What change must be realized as a result of this effort (expenditure)? What will this/these change(s) look like to the affected parties? Will they care and why?

03 Definition of Done

How does this effort, team, project, or program know when it is done spending money?

04 Constraints/Attributes

Are there parameters, boundaries, and/or attributes to which this engagement must adhere, meet, or otherwise evidence compliance. Examples: Financial (SOC), Health (HIPAA), Security (NIST), Privacy (CCPA), System Availability (5NINES), budget, time, capacity, risk appetite, traceability, auditability, etc.

05 Dependencies

What dependencies exist that may complicate, inhibit, or otherwise preclude this effort from successful completion? For example, will this solution sell itself into an existing market or do we need to create market demand along with introducing a solution? Are we innovating on existing things or green-field inventing? Do we understand the target market? Are teams skilled correctly?

06 Team

What roles were initially requested to make this effort happen successfully? How has this changed through the course of the effort? What exists today? What should exist? Is the team being simple enough? Are they thinking big enough? How frequently, if at all, is the team being given opportunity to assert, test, learn, and change? Is this an adaptive or inflexible project environment?

07 Work

How is work (deliverable) discovered, defined, prioritized, and realized? Is there more than one backlog? Is there more than one priority? Who are the stakeholders? How are they involved? What is the definition of done? What implementation choices have been made and how will they impact long-term solution viability, cost of ownership, staffing availability, training, and competency?

08 Money

Did there exist an idea of how much money would need to be spent in order to realize the desired value? If there is money awareness, are there planned versus actual details? A known run-rate? Remaining spend projection?

09 Commitment

What was the original delivery commitment? What is currently delivered? Is there a delta? If yes, why? If there is a planned versus actual delta, will this effort require remediation activities now, later, or never?

10 Risks

What are the risks which may impact successful implementation, daily operations, and customer delight? What is the associative probability of each occurring? What is the associative impact of each occurring? Particularly, though not exclusively, what are the elimination, mitigation, and/or remediation options for each?

To be a healthy, useful, value-driven and value-realized investment, projects of any size, in any size organization, all require these above elements in some way, shape, and form.

At the end of this effort, you typically have what you need to ascertain investment to return potential and make your recommendations to the Senior Leadership team.

Product Design & Development

Of Jellybeans and Elephants

Originally published on LinkedIn.

Imagine a world where you have the responsibility of building an elephant.

Will you start at the atomic or cellular level? Will you start at the skeletal system and work into the central nervous and circulatory systems? How about features, functions, capabilities, and constraints? Where will you start?

Elephant made out of jellybeans

How many attempts or iterations do you think it will take to get the job done completely, correctly, and usefully? How about just to get a first, working version?

Now imagine a world where the only time you learn the true value of the work you’ve done is at the end of each iteration. If all goes as planned, each iteration results in having more knowledge, experience, and value than at the beginning.

You make a commitment to deliver something, you actively work to deliver it as committed, and then you deliver. All as planned.

And as expected, after it is demonstrated to the stakeholders, you receive the feedback you need for the next steps. That feedback tells you one of three things:

  1. Let’s keep it.
  2. Let’s change it.
  3. Let’s head a completely different direction.

Given the size of an elephant, how frequently would you like to have feedback telling you where you are in relation to done?

Jellybean Patterns

In the below examples, look at each jellybean as a complete iteration containing Plan, Work, Demonstrate, Receive Feedback.

Each jellybean is viewed as a complete iteration containing Plan, Work, Demonstrate, Receive Feedback.

Consider these patterns: For someone who delivers daily, they can entertain change each new day. For someone who delivers every two weeks, they can entertain change every 14 days. And for someone who chooses monthly deliverables? Every thirty days. Remember, each iteration teaches you so that you can keep what you have, change to something new, or pivot altogether.

30 deliverables in 30 days compared to 1 deliverable in 30 days.

Author’s note: To keep this article simple, I’ve chosen to use simple numbers (1 and 30) in order to amplify the point through stark contrast. For the rest of this article we’ll discuss daily and monthly deliverables.

Since we’re building an elephant, I’ll take the liberty of suggesting it will take greater than one month. So let’s look at what a one-year delivery pattern looks like using 1 day and 1 month as units of measure.

360 deliverables in 360 days compared to 12 deliverable in 360 days.

Comparatively, if we accept that each jellybean is an iteration and that each iteration enables the same plan, work, demo, receive feedback pattern, the above pattern suggests that, through the course of one year, daily iterations enable nearly 97% more opportunities to learn and change than monthly. Likewise, if we assume weekly iterations, there are 80% more opportunities to change your mind than if delivering monthly.

Dial the iteration frequency into what makes sense for your company, teams, and client.

Remember, while you may feel you’re choosing iteration lengths, what you’re actually choosing is the number of times you develop, deliver, demonstrate, and learn across a period of time.

How many opportunities would you like to try something, learn, and change during a single project?

Let’s further explore the superpowers of delivering jellybeans instead of elephants. This time, let’s address unplanned change.

Jellybean Patterns and Mid-Cycle Change

Even with best intentions, small iterations, and high-performing teams, change happens mid-iteration. Not ideal. However, occasionally clients and teams experience new variables such as market shifts, attrition, mergers & acquisitions, products and services portfolio pivots, the team missed something, or the client realized they wanted a purple toaster instead of a red car.

Working to mitigate and manage change is good and normal. Eliminating change is neither realistic, nor healthy. Change will happen. Some change is good.

Plan for it. Invite it.

Imagine being in the middle of an iteration and you’re required to pick up work that was previously unplanned. Do you stop what you’re doing, reset the clock, and pick up the new work? Do you put it in the backlog and get to it when you’re done with the current effort?

Does your delivery pattern enable change while minimizing waste (**Where “waste” = time, effort, and deliverables that will not be utilized ‘as is’ or at all)? Change is driven by economic opportunity and client delight for the company, not project delivery convenience for you.

If you are practicing daily iterations, let’s say you started at 0800 hours and I asked you to pivot at 1200 hours. The potential project waste due to the pivot is 4 hours.

Similarly, if you are practicing two-week iterations, you started on Day 01 and I asked you to pivot on Day 6, the potential project waste due to the pivot is 5 days.

So it may make more sense to consider, if you are practicing 30-day iterations, you started on Day 01 and I asked you to pivot on Day 15, the potential project waste due to the pivot is then 15 days.

**Note: A more accurate waste calculation for these examples will be to consider (total_#people_involved) * (total_#hours_expended) * AVG(labor_costs_per_hour) + (overhead_costs (i.e., operational expenses))

30 deliverables with change and improvement inside 30 days compared to 1 deliverable in 30 days.

Now, using the same math argument mentioned above, consider what change looks like spanning an entire year.

360 deliverables with change and improvement inside 360 days compared to 12 deliverables in 360 days.

If value is realized by what is delivered and waste is calculated by what is not delivered, how important do you believe iteration sizes are to realizing value and managing the economic impact of waste?

3 Questions to Ask Yourself

Imagine this is your company and your personal money.

  1. How long are you willing to wait to find out if your financial investment was worth it?
  2. How long are you willing to wait to find out if your idea is even a good idea?
  3. How much will it cost you to change?

5 Steps to Make Sure You Get Results for Your Money

  1. Use a small team who strive for simplicity and thrive in change
  2. Use small iteration (batch) sizes to provide feedback now, not later
  3. Use a Plan, Work, Demonstrate, Receive Feedback pattern PER iteration
  4. Focus upon constant delivery (flow) over start-stop behaviors
  5. Plan for change. Stay small. Constantly deliver, assess, and change.

What Are You Going To Do Next?

Start with the elephant. Break it down into jellybeans. Deliver a predictable, constant cadence of jellybeans where each jellybean includes plan, work, demonstrate, receive feedback. Invite change.

It may surprise you to discover along the way, the client told you they wanted an elephant when they really wanted a platypus. How would you discover a platypus met the need if you only delivered an elephant sized iteration?

And this is only one scenario.

What if you don’t know for sure what you want? How much money are you willing to spend to discover it?

Imagine we’re going to spend $5000 of your money.

Do you prefer 50 iterations of $100 where you can change your mind every $100 and find out you wanted a platypus, not an elephant?

Or do you prefer 2 iterations of $2500 where you can change your mind twice, but remain committed to some form of an elephant?

I know what I prefer. Jellybeans enable me the opportunity to change when I need to, and to manage my risk, spend, waste, and time to market.

What does this look like for you?

Defining the Elephant

What do you do if your team, your company, or your client says they need an elephant but you believe they need a whale? Read my previous article, How to Know if You’re Adding Value.

Product Design & Development

How To Know If You’re Adding Value

Originally published on LinkedIn.

Helping a client get to where they want to go may be different than where you think they should go.

Consider the following: Your company has an outstanding reputation in the industry in which it operates. And folks who work at this company are considered to be some of the best and brightest. Personally, you are a highly educated, experienced professional in your field and one of the top in your company. A potential client contacted your company to explore a project idea they have in mind and you are tapped to vet the opportunity.

Your responsibility is to understand what the client wants and explore whether your company should pursue this opportunity.

For the purposes of this article, a client is anyone to whom you are to provide a product or service; whether internal or external to your company. Additionally, for this article, value is defined as value proposition, one or more desired outcomes; or otherwise stated, getting the client from where they are to where they want to be.

After listening to the client discuss where they believe they are, where they want to go, and their overall definition of done, you find yourself in an interesting position. From your experienced perspective, the definition of done is way-point #10 illustrated below. Based upon what you believe you’re hearing from the client, their definition of done is way-point #4.

Who is right?

Illustration of getting from here to there with a path up a mountain.
Illustration 1: Getting “from here to there” is relative to a client’s current context. Don’t just look at things stated and their implications. Look at the client’s current and historical social, cultural, political, market, and economic contexts. Looking at historical versus actual appetite for change informs the upcoming journey.

You both may be right. However, if your job is to serve the client and help them realize their vision for themselves, the client is right.

Rather than debating the merits of what you believe you know compared to what the client believes they want, meet them where they are.

Consider putting your predisposition(s) to the side and actively listening, learning, and discovering together. Given you’ve already seen way-point #4 on your way to #10 multiple times, you are equipped to counsel the client on options, priorities, risks, and decisions along the journey.

Get the client to way-point #4 as they desire. And while you’re working with them, you may discover they didn’t know about #10, didn’t believe they could get there, or #4 is actually what they need for now.

Consider the below steps to iteratively discover what is valuable to the client now, soon, and later.

Example Behaviors That Add Lasting Value

  1. Ask questions to understand where a client was yesterday, where they are today, and where they want to be tomorrow
  2. Provide observations regarding where they’ve been, where they seem to be currently, and where they want to go
  3. Provide multiple recommendations (options) to get from way-point #1 to #4 (e.g., 1>2>3>4 OR 1>2>4 OR 1>3>4 OR 1>4, etc.)
  4. Enable the client to choose what makes the most sense to them according to their culture, politics, timeline, budget, risk appetite, attitude, and aptitude
  5. Journey with the client by planning, achieving, demonstrating, and refactoring the solution together, iteratively (get them to #4)
  6. Help the client see and prepare for the future while delivering on their needs today (evaluate with them if #5 and beyond are valuable now, soon, later, or never)

What is described above is a purposeful partnership relationship between two parties where discovered and defined value drives decisions. It is a journey composed of goals, options, choices, and the ability to pivot, change, or otherwise re-scope along the way as more information is learned.

How Do You Know You’ve Added Value?

  • A 6-month engagement turns into 3.5 years
  • The client is willing to give you warm introductions to other companies and leaders who may need work
  • The client is willing to provide public/private references regarding the quality and value of work they received when working with you
  • The client is willing to stay in touch, contribute to, and/or be involved in other efforts driven by your company even after you’ve left

How Do You Get Started?

If you are not sure where to start, consider starting with the below three behaviors and the rest will follow:

  • Ask questions and then listen – Ask thoughtful, premeditated questions in order to learn. Clarify what you think you heard, then ask more questions to learn more. Favor questions over statements.
  • Deliver jellybeans not elephants – Practice committing to and delivering frequent, small, iterations of the larger planned deliverable across time. Do not agree to an outcome, disappear for awhile, work in a vacuum, assume nothing changed while you were gone, and return with what you believed was important two months ago. You’ll both be surprised (and perhaps disappointed).
  • Invite change – Frequent, small, iterative deliverables inform the client’s understanding of their reality and future. If your job is to help your client become more today than yesterday, then invite, and be prepared for, change as they learn and realize more with each small, iterative, deliverable.

Having a business, client, and revenue is a continuously earned privilege. To be the best at what you do, there will be no rest. Relationships, communication, and delivering value are hard. This article can help you tune your existing program of behavior, or even help you get started.

Challenged by Change Management?

If your teams struggle to pivot and adapt to changes, read my next article, Of Jellybeans and Elephants, which provides a path and new behaviors for your team to adopt and deliver value one jellybean at a time.

Product Design & Development

Go For The Win

The mantra “fail fast, fail often” is a rallying cry for technologists pushing organizations to become more Agile, more Lean, and to push teams to deliver faster. What is being delivered and how valuable it is long term, however, tends to get lost in the shuffle and “fail fast, fail often” can lead to a big fail when there isn’t a clear goal in mind. 

The 2019 FIFA Women’s World Cup was held in France and if you’ve watched any of the games, one of the statistics talked about is time of possession. During the course of a game, teams will drive forward to test an opposing defense, then pull back, sometimes all the way to the goalkeeper, and try again. However, as soon as the defense has adjusted and passing lanes are open the offensive side is on the attack again working towards the desired outcome: Score a goal.

Fail fast, learn often may not lead to a win in the world of digital transformation. You don't win if you aren't focused on taking shots at the goal. The first step is defining the desired outcome.
Fail fast, fail often may not lead to a win in the world of digital transformation. You don’t win if you aren’t focused on taking shots at the goal. The first step is defining the desired outcome.

In April 2018 Sunnie Giles, a Contributor, posted an article: How To Fail Faster – And Why You Should. She states, “In today’s complex business environment, where things are changing constantly, speed of execution is a lot more important than perfect execution.” She points to a concept of iterations creating positive autocatalytic feedback loops which eventually leads to radical innovation. This is a pretty common view from many leadership teams on how they want to push their organizations forward.

Radical Innovation

The words “radical innovation” stuck out when I read the article. I have had the privilege to work with a number of organizations throughout my career. In some cases, the leadership inside the organization coveted innovation and spent a significant amount of time and money building up innovation teams. The opportunity to drive the business into adjacent markets, new markets entirely, or to refine their existing market offerings to expand the organizations hold on a market. More often than not, the “radical innovation” introduced by leadership was either cut off from the rest of the organization or was actively under attack by more established parts of the organization and in the end, not effective in achieving the original business objectives.

Teams get locked into playing possession and lose focus on moving down the field and scoring a goal.

7/2/2019 World's Cup Score: England Vs. USA
This image illustrates losing focus. In last week’s game, England had more possession, more passes, and better passing accuracy but because they didn’t attack, they lost the game.

Why? Executives jockeying for power, friction between “the way we’ve always done it” vs. “the new way we want to do it now,” shrinking budgets, changes in priority to shore up existing market share. A large number of different factors all branching from a common thread: a lack of focus on the desired outcome. Teams get locked into playing possession and lose focus on moving down the field and scoring a goal.

Four Steps to Fail Fast AND Achieve the Desired Outcome

How do you prevent getting locked into playing possession? At Trility, we break the process down into four distinct stages: 

  1. Discover
  2. Definition
  3. Implementation
  4. Evolution

Each stage in the process has a clearly defined outcome to help ensure stakeholders can see the value along the way. Often companies are eager to jump straight to the Implementation stage and the “fail fast, fail often” mindset can achieve the discover and define stages – thus the desired outcome along the journey. However, unless you know where the goal is your team is just playing possession.

Join the Team

We are always looking for people who love problems and welcome the hard work required to solve them.

“You can expect variety with the type of work Trility’s clients are pursuing. We aren’t an X shop, we are a ‘get the job done’ shop, which means you’ll have lots of different opportunities to solve challenging problems with various methods.”  

– Eric Gerling
Product Design & Development

Don’t Forget the “V” in MVP

Minimum Viable Product, or MVP, is a common term used by business leaders and product owners to help drive quick, iterative, product development to get products released to market faster. The goal is to release just those core features necessary to put the product in front of customers to learn about customer needs and validate assumptions prior to larger investments in a new product. Release quickly, release often, and adjust the product based on feedback from customers.

Product teams today do a great job of focusing on the M, Minimal. Constantly asking the team and business stakeholders when new feature requests are made, “Is this a requirement for MVP?”, helps prioritize development efforts and keep the team focused on making a timely and relevant release. Business stakeholders on a regular basis can see the features being developed during frequent demos and can provide direct feedback which goes back through the same intake process grounded by the same question focused on releasing the MVP. When the cycle is managed by a proactive Product Owner, it can be an extremely efficient way to get ideas from a napkin at lunch to a product in front of customers.

Where Product teams struggle is with making sure the V, Viable, is taken into consideration as a team. Security, operational readiness, reproducibility, and scalability are all important parts of any product which helps validate the viability of a product. Unfortunately in the race to production, these items fall by the wayside and show up on the backlog. When the team does release the product and receive customer feedback, they’re often stuck in a challenging position of either picking up the items in the backlog tagged as After MVP or continuing to refine the product to keep customers engaged. As it should, the focus remains on the customer and meeting the business objectives for the product. The weight of the backlog eventually causes cracks in the team, cracks in the product, and a new round of questions for business stakeholders to consider regarding whether to refactor, rewrite, or sometimes, a new MVP to fix the problems from the previous MVP.

Continuous Integration, Continuous Deployment, Security by Design, Test Driven Development, Performance Testing, Infrastructure as Code – these are all terms many development teams are familiar with and actively promote inside organizations today. However, many of these items are the first things added to the backlog during MVP development when teams are racing against the clock. We need to do a better job as Engineers communicating to business stakeholders that each of these items are individually, and collectively, an important part of making a product viable.

We can still meet the needs of a minimal product by constraining the conversation in each case to the product being developed. The product may not have a need to support a thousand requests a second for the MVP, but we should ensure performance testing frameworks are in place and exercise the product on a regular basis so issues can be discovered early and often during the development process. The product may only require a small amount of simple infrastructure to be deployed to support the MVP, but the infrastructure should be built and deployed in code alongside the rest of the product so as needs change the foundation is already in place to support rapid growth. The product may not have a requirement to support a security standard for the MVP, but the application should be built following a set of standard security practices and validated regularly with automated testing to support a growing customer base. 

Viable – the ability to work successfully and securely.

Product teams need to ensure when MVP is defined, the product’s ability to work successfully after release is front and center during the development process. Minimal helps you get to the first release; Viable ensures you make it to the second.

Join the Team

We are always looking for people who love problems and welcome the hard work required to solve them.

“You can expect variety with the type of work Trility’s clients are pursuing. We aren’t an X shop, we are a ‘get the job done’ shop, which means you’ll have lots of different opportunities to solve challenging problems with various methods.”  

– Eric Gerling
Product Design & Development

Compressing Time-to-Value Requires Understanding What’s Valuable

The definition of value is subjective. Measuring expenditures is objective. If you ask someone in your company or team to define value, what do you think they will say? Will they discuss financials? Will they discuss projects, software releases or widgets created? Do you or your team define value to a customer by counting things?

As a quick exercise, define the value of your pants; not in terms of money, but in terms of value to you. Simply put, can you measure the value of your pants? Simpler yet, define the word itself – value. Like choosing wine, art, and music, defining value is subjective to whoever is shopping.

In business, we use cost accounting to count things. Ironically, cost accounting does not define value for a customer, nor does it delight a customer. It simply counts things.

When we use cost accounting to measure, we’re being fiscally responsible. However, the focus on the cost of things leads companies, teams, and individuals to perceive that cost of acquisition, cost of ownership and return on investment math defines value. While the company that sold you pants can measure their investment throughout the entire supply chain down to the point of sale, that math doesn’t define how you value pants, their brand or company. Were you able to measure the value of your pants? What would make you purchase a second pair of those pants?

Taking software projects and breaking them down into people, time, and cost helps us count things. In order to deliver product and service solutions to customers, we count things. Does that seem weird? Does it seem weird we can count all of the things in a project, feel good about ourselves, and still have no idea what the customer actually values?

Does knowing the cost of all the things in a software delivery chain mean we know when we’ve provided value to the customer? Unfortunately, it does not. It only suggests we know how to count.

If we can objectively count money, but we cannot easily measure a customer’s perceived value of things, as business and technology leaders and team members, how do we increase the probability of making first-time and recurring sales? Most of us are in business to make a living. Making a living requires money, which requires sales. If we don’t know what a customer values, how do we make sales?

“What!?” you say to me. “I’m not a sales, advertising or marketing person. That’s their job to do that rubbish. I just deliver stuff.” I’m not a marketing, advertising or sales expert either. However for those who are, as a technology leader I can help them do their jobs better by providing shorter time to revenue windows which helps them discover shorter time to value windows for both the company and the customer.

In other words, marketing, advertising, and salespeople need options every moment of every day to adapt to varying customer scenarios, gain market-share, crush competitors and make money to pay our salaries and business expenses. And they need them now, not when the business and/or technical teams can get to it.

What is the time between having an idea and delivering the idea in order to delight a customer and generate revenue?

In your company, is the flow of a product solution from beginning to end smooth like fresh ice on a hockey rink and as fast as a hockey puck? Or is it more comparable to the starts and stops of a muddy, variably pothole laden road? Figuring out time-to-revenue and time-to-value factors depends on understanding how product solutions flow through your company.

If you build software solutions and/or run software operations for a living, what do you think about the following questions?

  • Why are there so many steps to get from idea on a napkin to implementation?
  • Why are there so many tools in the delivery chain?
  • Why does it take so long to find out if we broke something that worked yesterday?
  • Why can’t we know whether the product meets company standards all of the time?
  • Why do we test so late in the process potentially delaying our project?
  • Why can’t we know if we’re compliant with industry regulations every time we build software, every day of every week instead of during third-party audits performed quarterly and annually in arrears?
  • Why can’t we deliver small portions of the larger solution that can be marketed, advertised and sold along the way instead of waiting for everything to be finished before we can even begin advertising, selling and making money?
  • Why can’t we find a way to deliver at the highest quality and highest velocities at the same time? Why are they treated as mutually exclusive?
  • Is information security and performance really something I have to kick down the road until later?
  • Why does it seem like our projects are black boxes of magic until the very end?

Consider this: Sales people are expected to provide verifiable value that is daily, weekly, monthly, quarterly, and annually measured in qualified leads, follow-ups, sales and revenue with non-negotiable baseline margins, but people who build software products take as long as they take and spend as much as they spend?

If you're responsible for delivering solutions that enable customer delight resulting from sales, marketing and advertising successes, the distance between having an idea and realizing the ability to make money with said idea is called – time to revenue. 

The distance between having a product and knowing what product the customer actually wants to buy is called – time to value.

Question: Organizationally and operationally, what do you need to change in order to realize shorter and more frequent time-to-value discoveries?

If you’d like help figuring out how to compress the time it takes to get from an idea to making money while also including security, performance, quality and reliability from the beginning (instead of later), we’d like to help. Or if you’d like help determining how to more quickly and frequently discover, rediscover and provide recurring value for your customers, the teams at Trility Consulting know how to help you get from where you are to where you’d like to go.

We evaluate your business goals and current state of operations. Then we work with you to implement solutions which help you get there. We use 100% software-defined, continuous delivery behaviors including continuous test-driven development, continuous inspection, continuous compliance, continuous vulnerability assessments, continuous penetration testing, software-defined infrastructure, serverless architectures, secure enterprise-class cloud ecosystems and more. This is simply what we do and how we live even for our own projects – and we’ve been doing it for quite awhile.

We’ll help you discover what time to value looks like in your team and operation. And your customers will thank you for it.