estimated reading time < 5 mins
Over the years, I have had the privilege to be asked about and give insights on how to maximize product development success, and for such a big question, where do you start? There is so much to say on so many aspects, all of which are important, but I figured it would be a good idea to consolidate my thoughts on it and share broadly.
Given such a broad subject, I have to limit the scope and not include
- Business strategy (models) – good products tend to sell themselves but still requires more than just that, and although I have opinions on this matter, I will set aside for now.
- A Career in Product Development – here, too, I have much to share and disagree on many aspects of path and education. Although what I share below could contribute project and individual success, it will not be the focus/intent.
- Organizational structure – how to find, assemble, motivate and work with the right people to achieve the results.
Rather, I want to talk about an overall framework to increase your chances of successfully building something or at least getting started. Hopefully, it will benefit others, but it will allow me to make sense of the complexity or, at the very least, a good enough answer without having writing a book about it or sharing tons of links.
There are many frameworks, principles, tools, and practices in Product Development, but in my effort to synthesize, they point to these steps
- DESCRIBE
- DESIGN
- DECIDE
- DELIVER
Yes, it seems a lot of the good words start with D.
Delivery would include validation that the intent or description/vision was achieved, if not or if improvement needs to happen then reinforce with learning/feedback then rinse and repeat.
DESCRIBE – or define. In talent show terms – what’s the dream? What do you hope to accomplish? To the more informal – can you paint the big picture? To the more formal – what are your goals and objectives? Are there constraints, are those facts, and are they negotiable or not?
DESIGN – how are you going to accomplish it? Sometimes, there is more than one way to accomplish, and one is the best. Sometimes, there are no known ways to achieve the thing described, just ideas. What medium, what channel, what would the flow look like to reach the destination?
DECIDE – when you have many ideas and options, which ones do you choose? What if you chose wrong? How long should we think about it?
DELIVER – make it happen. do it.
In coming up with this, I had three starting points
- In my experience and knowledge, what were the common causes of failures?
- I have always looked up to design thinking in building things – how does that fit here?
- In execution, I have always looked up to DevOps – how does that fit here?
What are some common causes of failures, and which steps might address it?
- A failure of imagination = Describe and Design.
- A failure in alignment – needing to be on the same page = Describe.
- A failure in execution = Deliver.
- Delays – inefficiency to Deliver.
- Delays – untimely decisions (paralysis) = Decide.
- Nobody wanted to use it = Design.
- Not enough people want it = Describe (constraints)
It’s alright so far; improving on those steps could avoid some of these failure traps.
While looking further into the “not enough people want it” item, things come to mind: the product needs to have a bigger market, may be too expensive (pricing), or may not be well-known enough (marketing). The Describe step is broad enough to require a different design (strategy/plan) for pricing, marketing, and software development. A self-similar (fractal) pattern emerges, or a subset of the steps spins off the main path. For example, although towards the same described dream, you need a product interface design, an architecture design, a security design, and a pricing design, then for each aspect of those, you will have many options and have to make the decisions and deliver them. So this Describe->Design->Decide->Deliver (from now on also referred to as DDDD) happens in the bigger picture (e.g., business) as well as in the smaller picture (e.g., daily or task level). Or Describe -> spinning up 2+ Design steps in parallel the same way that Decide output could be status-quo and therefore Delivery is a no-operation. I have always thought and said that life is a series of decisions, but in more generalized terms, a series of these DDDD loops.
One description (dream) could require spin-offs of many aspects
Or in the spirit of reinforcement learning, iterate on subsequent steps
So now what?
I want to avoid reinventing the wheel, but my goal of making sense of the concepts I have come across still stands. I will continue to test this framework until it breaks (by myself or as I get feedback from others). For example, the Double Diamond Design Thinking Framework involves “discover, define, develop, deliver” (again with the Ds). It overlaps with this a lot but does not seem to cover indecision or DevOps which I put a lot of stock on. It also has a different idea of developer+deliver. I will try to break this framework including seeing if this applies outside of software for my amateur woodwork, automotive, trading, or random house projects.
Assuming these are key/fundamental steps for developing something, there must be frameworks to maximize the success of each step, and I will explore those frameworks.
- Describe – I am excited to know the good frameworks for framing things. I have yet to look much into this.
- Design – I already love Design Thinking, so that’s more than a starting point for me here.
- Decide – I have favored decision-matrix or grid/multi-criteria analysis unknowingly over the years, but there are tons of decision-making frameworks out there; it’s more than dizzying (OODA, TDODAR, Cynefin, RAPID, etc) and no shortage of acronyms but it will be fun.
- Deliver – DevOps (DORA) might have more than enough to explore here.
Stay sharp, and keep building things! I will keep in touch.