Bad ideas are part of the plan: Working differently to build custom software

The chemist Linus Pauling is credited as saying, “If you want to have good ideas, you have to have many ideas. Most of them will be wrong, and what you have to learn is which ones to throw away.”

That last part sounds almost glib, but knowing which ideas to throw away is no small thing, especially in the world of custom software development. Our clients invest significant time, energy, and money into building products to make their users’ lives better. We have to ensure the ideas they invest in are the right ones.

And we do—in each and every engagement. We’re able to repeat our success because we’ve adopted a way of working that lets us consistently create new value for our clients and their users. Here, I’ll explain that way of working.

The 6 principles to work differently

Maybe you’ve heard of the 6 Principles to Work Differently. Currently the intellectual property of Salesforce, they were originally developed by Chris Conley, Nina Ziebarth-Pavlovich and myself while we were working at gravitytank. Now that I’m Head of Design at TXI, I'm helping us embrace these principles in our work.

So what exactly are these principles? They’re a collection of mindsets and behaviors that, when consistently practiced by a group of people, lead to innovative outcomes:

1. See and Experience: We interact with the world beyond our desks, starting with end-users. Getting as close to their experiences and perspectives as possible—combating bias with empathy—to ensure we accurately identify and document their needs.
2. Dimension and Diagram: We break down our observations and restructure our findings to better understand the problem space. We visualize our shared understanding using maps and frameworks to align on insights and mental models.
3. Question and Reframe: We interrogate our clients’ (and our own) beliefs and orthodoxies. We reframe problems and opportunities to challenge those assumptions.
4. Imagine and Model: We make our ideas tangible and shareable—concepting, sketching, and wireframing what’s plausible, probable, and possible.
5. Test and Shape: We study actual users engaging with what we’ve sketched, prototyped, or built. We ask for their feedback with every interaction and use that input and our observations to improve what we’re building.
6. Pitch and Commit: Throughout the process, we pitch concepts and ideas, collect feedback and align on preferred paths forward. We make sure everyone is on the same page throughout the engagement, building conviction for what to do next.

As I said, though, these principles currently exist as part of a Salesforce initiative. They’re not secret and they alone don’t make us unique. That comes from how we bring them to bear on the work of custom software development.

De-risking the project at every step

The Six Principles to Work Differently emphasize the importance of investing time at the start of an engagement to understand the current state.

Before any solutions can happen, we have to have a clear sense of an organization’s desired outcomes and of the actual problem we’re trying to solve. We take time to step back, explore, iterate and test our assumptions.

At the same time, we practice dual-track agile design and development—a way of working that emphasizes launching products in the leanest, fastest way possible. With design and development working in concert to continuously inform, improve and accelerate each other.

So how do these two ways of working coexist without annihilating each other?

Maybe the best way to understand their relationship is in looking at the worldview that underlies both.

Agile assumes a product will need near-constant updates and tweaks as bugs emerge and conditions change. Its sprint structure aims to solve small problems and make small improvements—continuously. There is no assumption the product will ever become “final” and static.

In other words, it’s a development style reflecting the conditions of our fast-moving world.

The six principles were developed for that same world. They emphasize the importance of seeing and experiencing what users currently do rather than relying on dated or secondhand research. They emphasize sketching ideas and sharing them to get feedback and see as soon as possible whether something works.

When applied to custom software development, the combination of the six principles and agile development practices means we’re always de-risking the next phase of a project—and we're always looking to improve the experience.

Working differently in action

I realize this is somewhat abstract.

So let’s look at an example of how TXI’s approach to working differently might solve a non-software business problem. In this case, an organization’s sales team is spending too much on their corporate credit cards.

This is not only costing the organization more than it budgeted for client entertainment, it’s also creating tension between sales managers and their teams and between the sales team and accounting.

In a typical business setting, leaders might get together and think up solutions: for example, maybe they decide the consequences for overspending need to be more severe. And, without any further information, that may indeed seem like a good solution.

But let’s approach the situation using the six principles.

The organization’s leaders go in thinking the problem is salespeople are spending too much on company credit cards.

But then they actually talk to the salespeople. They ask them what’s going on. And they find out that the sales team feels the current consequences for overspending are too harsh––that they demonstrate a lack of trust and a lack of gratitude for the salespeople’s work. Moreover, the salespeople’s conversations with colleagues elsewhere lead them to believe their compensation is too low, and they’re spending more on client events because they feel they’re entitled to.

The org’s leaders also talk to the accounting team, whose members are just tired. While the salespeople are the worst offenders, everyone misuses their company cards––some intentionally, some not. The accounting team wants to stop chasing down receipts from their colleagues.

Once they’ve talked to users, the leaders see the problem isn’t (just) overspending. Both sales and accounting feel overworked and underappreciated. Stricter penalties would have probably alienated both groups and may have led to expensive turnover.

From here, the leaders can brainstorm solutions: the more, the better. Some will be bad, but with evaluative feedback from sales and accounting, they’ll validate which ones have real promise for impacting the issue. Example solutions:

• Just pay everyone more!
• Hire a bunch more people
• Communicate better around compensation structures
• Introduce software to automate accounting work
• Use cards with dynamic spend limits managers can control in real-time
• Hang “stop complaining” signs around the office

The leadership would then model these ideas as lightweight prototypes, refining them and test-driving the concepts with users. With feedback and continuous shaping, they’ll gain confidence in the most viable solution, then pilot and study it to keep refining.

This way of working prevents organizations from investing resources in the wrong projects. It ensures they solve the right problems. And it does so in a consistent, collaborative and repeatable way.

Embracing an evolving process

TXI didn’t arrive at our current way of working overnight. We’ve embraced a variety of frameworks and approaches as we’ve refined our process for building custom software. In our earliest days we advised clients on how best to integrate existing systems and software, then started building custom software where we saw gaps in the solutions. Moving from waterfall to agile allowed us to better manage risk and complexity for our clients while trading perfection for pragmatism. Our burgeoning UX, UI and user research practice was accelerated with Google Design Sprints and further cemented with the adoption of design thinking and the Six Principles. So in many ways, the product innovation we deliver today has been a natural evolution in the way we think (mindset) and work (behavior) with each other and our clients.

We operate the way we do today because we’ve found it consistently allows us to confidently throw away “bad” ideas, so we can act on the right ones.

My expectation is we’ll continue to evolve. Just as a product can’t stay static and continue to deliver the best possible outcome to a changing user base, an organization like TXI must continue to experiment and explore new ways of delivering outsized value to our clients.

But I’m also confident our way of approaching our work—which involves actually seeing and understanding our environment, along with questioning and reframing our current assumptions—has led us to innovate consistently and will continue to for years to come.