We’ve been working on some terrific discovery stage projects in my team. We are all super pumped about it. Team has come up with some fresh ideas and a vision to execute on. However, we are very much seasoned in working within fixed structured, mature projects. Usually, we either work on small pieces or large capabilities that are fully planned out. Our projects tend to carry a high level of certainty around what needs to be delivered.
With discovery projects, this is not the case. Creating products or capabilities from ground up is an erroneous process. Team fundamentally has to be dialed into trying out what “feels right”. This means to take features and play with them for a while. Spar with your peers about insights and learnings. Lots of intermediate demos and candid chats about what’s acceptable and what doesn’t feel quite right yet.
Ken Kocienda writes that this is how a lot of Apple products were developed when he was at the company. In his book Creative Selection, he works through the development of Safari, iPhone and other core products we use daily. Apple’s a very secretive company. They have no means of gathering broad feedback. So they spend time working through internal feedback from demo after demo.
“Learning to play” isn’t something that needs to be taught to anyone. We know how to do that inherently. With curiosity comes the need to explore. However, in a highly process oriented oragnisation, people learn to restrict themselves. They learn to grab Jira tickets with well defined stories. Processes train the team to stop “playing” with ideas and instead, achieve high velocity. We favour tasks over customer outcomes.
That’s why we end up needing process hacks like Hackathons (I don’t like them!).
Furthermore, when it comes to planning, everything is etched in stone. We do a design for feature X, then we implement X for a week, then we ship it. Creating products tend to be more of a creative process that is a lot more fluid. In larger organisations, we don’t know how to report these challenges up the chain either. If product decisions change with new learnings, leadership asks “why didn’t we see the risks before?” Yes, my magic 8 ball never arrived in time. Team itself assigns no time to learn at all. First idea is assumed to be perfect; implementations are taken to scale at will to all scenarios; code is assumed to be bug free.
3 things that would help…
- We need to allow “play” time for ideas, especially at the early stages of projects. These learnings can lead to better product implementations and more accurate timelines. (According to this book, timelines are best predicted by looking at 3 things: previous similar projects, hiring experts and doing lots of prototyping early.)
- Go back to real agile, not huge gantt charts. Make iterations that are outcome focused.
- Share insights and learnings and how that is affecting the product with stakeholders and team.
Leave a Reply