Practice agile, iterative change to refine products and build company culture

I firmly believe that principles as much as products drive a company’s success. A startup may have a persuasive brand story and good public relations, but if it’s internally inconsistent — if its employees and executives cannot identify its central values — sooner or later there will be trouble.

At Heap, the analytics solution provider I lead, a defining principle is that good ideas should not be lost to top-down dictates and overrigid hierarchies. Although I’m the CEO, I recognize that I don’t always have the best view simply because I’m on top of (the) Heap. The best results come when you approach leadership like you would create a great product — you hypothesize, you test and iterate, and once you get it right, you grow it.

Most of us have had the experience of receiving a sudden decree “from above” that makes little consideration for the actual, as opposed to the theoretical, situation of people on the ground.

One-and-done decrees versus agile, iterative change

I’ve used this method in the businesses I’ve managed. The scientific method, with its cycle of observation, reporting, hypothesizing, experimenting, analyzing and reporting, is a powerful tool for product and process development.

While my process isn’t quite as rigorous as the scientific method and tends to sprint where science slowly marches, it’s based on similar principles. Before I describe the system, a warning: Although it’s a simple way to iterate new concepts and evaluate new designs, my method requires a genuine commitment to the principles of cooperation and collaboration. In an organization predicated on hierarchy and strict structure, it could be a recipe for groupthink and unearned consensus. Iteration is not, however, a justification for delay: There may be several iterations of a project, but those iterations follow each other quickly.

Most of us have had the experience of receiving a sudden decree “from above” that makes little consideration for the actual, as opposed to the theoretical, situation of people on the ground. You know the kind of thing I mean: The sales team in the saturated territory is told they must increase revenue by 20%, the already lean division is told to cut costs by 10%. Moves like this are bad for morale; they inspire resentment and cut corners. It’s precisely to avoid this kind of top-down debacle that Heap takes a collaborative and iterative approach to change.

Passing ideas back and forth

We put our business’ best minds to work to devise an initial prototype of whatever our business may need. That prototype might be a minimum viable product for commercial release, polished messaging for our forthcoming releases, or even a compendium of internal workflows.

But we can’t consider a project perfect if it’s never been exposed to the world outside the office. Whether we’re crafting a project, tweaking our messaging or establishing pricing tiers, we test in the real world. We show products to consumers, prospects and advisers, who invariably have needs that we hadn’t anticipated. The testers’ concerns may send us rushing back to the drawing board, but that’s accepted and expected. It’s the testing and refining that leads to the best product. While some businesses prefer a rush to market, we’ve observed that doesn’t work. A rushed product will frustrate users, lose word-of-mouth enthusiasm and provide an opportunity to our competitors.

But this isn’t just for product releases; we adopt a similar strategy for determining changes inside the company.