There are a number of different models/approaches/frameworks for product strategy and delivery. Many of them I don't like terribly much, because of a tendency to break apart the sum components (business strategy, design, delivery) into disparate phases - often with gating process in between. This is mostly unhelpful, and not conducive to responding to change - either because of what is learnt along the way, or some other business factor. So, recently somebody asked me what my ideal approach for end-to-end product development looks like. It's a straight-forward question, but not an entirely straight-forward answer.
Note: I found this post in 'draft' from March 2012. It looked worth finishing, so here it is:
Understanding the company, and their business
First of all, I want to know how decisions get made, and who makes them. This isn't about product strategy at all, but it gives a view of who needs to be influenced, and ideally, how to go about influencing them. The power brokers' approach to decision making usually has a fundamental impact on what gets produced and how it gets done. The best designers I've worked with are master communicators who are able to influence above all else.
Then I want know about the existing delivery model.
Is the team scarcely but competently resourced? Willing to recruit specialists for the project? Open-mindedness to lean delivery methods? Or is it more toward a bloated team of laggards, running sluggish production processes under a hierarchy of middle managers and tedious command and control culture? Again, this isn't product strategy, or design, but it sure impacts on both.
Opportunities, Objectives and constraints
Let's get some definition on what the opportunity looks like. This is the part that I usually find to be the most amusing. "We have $100,000 to spend before end of Financial Year" doesn't sound like a real product opportunity to me. Nor does "We need an app".
It's so important to get deeper than these vague notions of why we're all here. In an ideal world, there's a well defined business strategy, someone has done some analysis and identified a clear and specific opportunity with a tangible, measurable objective or outcome in mind. Even better if there's a customer analyst on board who has already brought to light some insights and behavioural trends of existing customers.
However, it seems rare that this is actually the case. I've never regretted spending the time up-front to get a fuller understanding the various project sponsors, stakeholders and subject matter experts, what motivates them, what they see as opportunities and any potential objectives.
In the past, this has happened mostly by osmosis, mostly because I've been part of a client-side team long-term and surrounded by or immersed in the mechanics of how business gets done. Increasingly, as I'm spending more time consulting with new businesses, I see that techniques like the Business Model Canvas can quickly illuminate the nature of customer relationships, value propositions and ultimately how revenue is generated.
It's so tempting to just 'jump on the tools' and start designing before mapping out the business model first. I find that one way or another, this exploration must happen first. Where a team moves straight to 'solutioning' - before exploring - the concepts or designs merely become the vehicle for exploration of the business opportunity. This can work if you're sketching high level concepts with the explicit intent of exploring opportunities collaboratively with the client. But if your producing something higher fidelity, like wireframes, then often the effort is misspent as you discover that the 'solution' doesn't align with the business opportunity, meaning you need to start over.
Concept generation and validation with UX Methods
The real fun begins now, and there are limitless options on how you might approach this.
My favourite method at the moment is the Pop-up Design Studio. In a nutshell, this is opportunistic, guerilla customer collaboration, organised in a way that allows for rapid ad-hoc generation of ideas, collaborative sketching and iterative testing and refinement of ideas within a very short period of time. One brilliant example of this in action is Lastminute.com working with ThoughtWorks in London for the latest version of the lastminute.com.
Everyone has their favourite methods. I'm a fan of collaborative workshops, and regard Jason Furnell's approach to be especially nice, both from a method point of view, as well as his execution of the method. Check out his blog, especially this article about his process, and these method cards.
Other favourite methods that I like to use are:
- Task analysis
- Content audit, analysis and strategy (refer to Sara WB and Karen McGrane)
- Prototyping (paper or coded)
- Qualitative customer testing
Minimum Viable Product and Continuous Delivery
As early as you can, build the foundation of the 'right' product, measure it, learn and iterate. This is principle five in Eric Ries' definition of The Lean Startup http://theleanstartup.com/principles
Everything that's been done before this is about knowing what the most compelling outcome should be - both in terms of customer needs and how revenue is generated by meeting those needs. Once the essence of the product is built, hopefully the fundamentals are correct, and you can begin to build out more of the product in response to insights from observing and measuring real usage.
If you're slightly less lucky, you may find that things are not in fact as expected, and some change - possibly major change - is required. If that happens, use those insights to move in a new direction. That is, 'pivot'. And be reassured that you haven't bet the farm on an idea that turned out to fail in reality.
So, that's what I think about product development. Today.
It will change. I also believe strongly that successful technology products requires a lot more than idealised design. Successful products happen when solid business strategy meets customer-centred design thinking, in concert with sound engineering of technology.
Business managers, designers, technologists. We're all friends here.