Skip to main content

Design Sprint and Dual Track Development

Context

The current typical model of starting a large program is to have a discovery workshop for the program followed by detailed project inceptions. The project inceptions are spaced and detailed.

There are not a lot of discovery workshops we do that is mutual discovery. It is more of sense making of an earlier discovery process.

The Pitfalls and some thoughts

With the discovery process feeding into the project Inceptions was great. it gave direction. However, validation of the direction based on feedback from projects seems to be missing.

The reason the feedback is missing is 2-fold:

#1 - The discovery workshops don't seem to have a cadence with the project Inceptions

#2 - The team that does discovery workshops is to involved with the project inceptions and vice versa,


Some Thoughts around the problem statement

  • Not all the discovery workshops are sense making.
    • Yes not all of them. We have had the opportunity to work with clients that have involved us in their discovery process. 
  • Not all discovery workshops use a separate team.
    • Yes, The project team is involved with discovery as well However, the typical structure has been that the discovery workshops tend to morph into a program inceptions.
    • Post that, we plan one or more project inceptions. This process does not allow us to have the project teams involved in discovery since the project teams come in a lot later than the discovery workshops.
  • Why do you think feedback needs to go from project inceptions to discovery workshops
    • What we find during our project execution is also important to consider for the program direction. This might influence other projects in the program as well and hence is important to feed into the discovery process to set the right direction.


A few Ideas discussed

  • How do we provide feedback from Project Inceptions to discovery workshops?
    • Since the cadence for a discovery workshop is pretty long, the feedback takes time to percolate back. The best way for us to accomplish this is to have a cadence that is parallel to the Project execution.
    • We discussed the Dual track development model as discussed by Jeff Patton. We used the picture below for our conversation: http://jpattonassociates.com/dual-track-development/



  • What are the Key thoughts of Dual Track Development? [Shamelessly copied from the website]
    • Discovery and development are visualised in two tracks because it’s two kinds of work, and two kinds of thinking
    • Discovery is a necessary part of product development. Practice it with the same agile and lean principles in mind.
    • If we’re doing discovery right, we substantially change and kill lots of ideas.
    • While a product manager, designer, and senior engineer may lead and orchestrate discovery, they must involve the whole team in discovery tasks wherever possible. Keep discovery work and progress visible to the whole team.
  • Is this going to be time - consuming? It typically takes a good amount of time setting up the discovery workshops?
    • Yes it does take some time. We can draw some inspiration from the Design sprint concept that Google venture uses. More information here: gv.com/sprint/
On Monday, you’ll map out the problem and pick an important place to focus. On Tuesday, you’ll sketch competing solutions on paper. On Wednesday, you’ll make difficult decisions and turn your ideas into a testable hypothesis. On Thursday, you’ll hammer out a high-fidelity prototype. And on Friday, you’ll test it with real live humans.
Labels:

Comments

  1. RobertNelsonApril 20, 2022 at 7:07 AM

    Thank you for posting such a great blog. I found your website perfect for my needs. Read About Design Sprint Online

    ReplyDelete

Post a Comment

Popular posts from this blog

The right business model for your product

How would you decide what is the best business model for your product? Deciding on the right business model is very important for the product. It does not necessarily mean what is the price of your product. There could be no price for your product - though that is a myth. For example, we think google or Facebook is free. However, we are never the customers for Google or Facebook. It is the advertisers that are its customers. What we need to figure out when we decide on a business model are as follows: Who is my target audience? Who is my customer What is the price. How is the support model going to work Who are my partners While we do not absolutely need to price a product, we need to understand how we would make money. For example Open ERP does not price its product. However, its product is not the ERP software but really the hosting, service and training that it offers. While pricing is an important part, what is more important is in realising who is you...
Post a Comment
Read more

Finding your target audience

The biggest task of the product manager is to find your target audience. Typically it is a very tight rope walk. You define it too narrowly and you would struggle to generalize the product later. You define it too broad and you would struggle to satisfy a lot of people and the product might not take off at all. There is this awesome post by Dave Mcclure on why Niche target segment works. Blog link here . What he says is mostly right and that is what we did as well. We did it mostly by accident. We had to define our niche because we could only talk to those kind of retailers and get data from them to start developing the data. It did have its upside. We were very clear on what we wanted to develop and we are slowly talking to retailers and adding more scenarios. As we are doing this, we are also talking to a slightly different set of retailers. This helps us incrementally build our product while also generalizing the existing features. In our case, we did not fin...
Post a Comment
Read more

Constructing the Product Roadmap

When I started out in the team, I was tasked out with coming out with a plan so that we can demonstrate the product with real data. The idea was to demonstrate it to our prospect with their own data and win them over. However, when I started working, I found out that what we lacked was not a plan but a vision. I quickly put together a one day workshop with our team and our product owner. When we started talking, we talked about several things and figured out that we needed a plan of various proportions. We needed a plan that could help us one the following: Provide a focus for the long term with near term focus on just one thing Help us talk to prospects on what we are going to do Help us decide on when we would need to focus shift on which function - Engineering , sales etc We also did a quick “Product in a box” exercise so that all of us in a team can practice and imbibe the elevator pitch. We needed this since we had to do this pitch at several levels - Inter...
Post a Comment
Read more