Agile software development is everywhere. You're probably using some form of it yourself. And, that's probably good, assuming you're actually delivering value with agility.
These days, I constantly hear about how "shipping working code" sooner trumps everything else. When it comes to designing for analytics though, I don't always agree.
It's hard to build and ship quality if you have no vision for what "good" is. When I am helping a client redesign or design a new product involving analytics, there is usually a good "business hunch" about the potential value of my client's data to their customers. However, there is often a big gap between these ideas, and their customer's ability to actually experience this potential value. Good product design fills this gap, and is what enables data to become a value that customers can experience. However, a traditional agile process with design and engineering working in tandem from day 1 is probably not going to yield you a quality product you can iterate on quickly.
Most of the time, my recommendation for clients comes down to this:
Design for Gold, settle for Silver. Don't shoot to design and build a Silver product out the gate.
Agile pushes us to design and code together, and to get something decent out the door as fast as possible that can be evaluated. However, not every product type is conducive to this approach and [especially new] analytics products are one of them. (Not to mention, so many teams never actually evaluate and test their product with customers.)
I push my clients to put aside timelines and engineering constraints for a bit and work with me to design an initial "Gold" vision for their product. Once we have that vision, we then get out the scalpels and negotiate the design with engineering to something feasible ("Silver") that can be delivered within acceptable business timeframes.
What do I mean by Gold? I like to say it's a vision that is closer to a "moon-shot," but not a "Mars-shot" in terms of feasibility.
Here's why I suggest this approach:
- It's easier to arrive at a technically feasible "Silver" design early...if you know what your Gold vision is up front.
- Your product managers / stakeholders are likely to uncover new values, ideas, and strategies and rethink the product backlog simply by going through the design process and seeing what their imagined "customer value" actually looks like once manifested in a design.
- Engineering can incur substantial technical debt if they don't know what Gold looks like early on. It's much easier to get to Gold from Silver more quickly if Gold has been defined (designed) earlier because the technical architecture is likely more "on track" to facilitate ongoing development toward the Gold version.
- A Gold vision helps rally product teams around a single vision that is actually tangible. "Product strategies" and PPT decks with value buzzwords don't mean a lot to engineers and designers. The buzzwords only become meaningful when the team has a common vision (design) that manifests those ideas.
- A small amount of design-only time up front to establish a Gold vision will probably enable faster product iterations, even if your first release is closer to "Bronze" in terms of quality.