Product Discovery Diary
When product managers and designers move from the very linear, Waterfall-based processes, to the much more iterative and exploratory discovery-based process that I and others advocate, they sometimes take a little while to appreciate and adapt to the fast pace and rhythm of product discovery.
The purpose of this note is to try to give you a realistic sense of what the heart of product discovery is like.
What makes this a little tricky are the many variables such as the type of product, the size of the effort, and the stage the product is in. But I¹ll try to describe a fairly typical situation. I did fabricate this scenario however because I want to illustrate as many of the important points as I can.
Week 1
Monday:
– Reviewed and discussed the opportunity assessment with the key stakeholder, in order to get a clear understanding of the business objectives.
– Held an initial session with my lead designer and lead engineer and came up with a set of product principles.
– Followed this up with a brainstorming session we have some great ideas for this product.
– With the lead designer, we came up with a first-pass at the key personas.
Tuesday:
– Sat down with my lead designer to refine and prioritize the personas, and discuss and prioritize the key user scenarios.
– Met with user research to identify the names of some potential charter customers; made several calls to screen for good candidates.
– My lead designer is going to put some of our early ideas into a quick prototype.
Wednesday:
– Sat down with my lead designer and lead engineer to look at the early prototype of the first couple scenarios; lots of discussion, this is turning out to be more complicated than we originally thought.
– Reviewed our product principles we created earlier; this helped us remember what¹s important here and we simplified our approach considerably.
Thursday:
– Sat down with my designer and also the key stakeholder to look at the prototype, which is still very early but it now has the three key scenarios in it. The first thing we realized was that there was a bit of a disconnect between what we have been thinking and what the stakeholder was thinking, mainly because we each have some different assumptions about our users.
– Did some more phone calls with target customers; I have now identified six companies that have agreed to serve as charter customers. The most encouraging news is that people seem to be genuinely interested in the problem we are trying to solve. They don¹t have a good way to do this today, and they say that if we could solve this for them they would really value this product.
Friday:
– We walked through the updated prototype with our lead engineer. He is cautiously optimistic about the viability of most of the key ideas, but he had two significant issues. The first is that one of the ideas looks like it could end up being fairly expensive to build and potentially a very slow operation. He wants some time to look into this. The second issue he had is that he thinks he may be able to eliminate the need for some of the data we collect because he thinks we can derive this data based on other information we already store in the database.
– Met with legal and showed the very early prototype just to see if any of our ideas raised any flags; one area being looked into by legal with answer coming next week.
Week 2
Monday:
– We took our prototype to our first charter customer this morning, where we met with four different potential users. I brought along my lead designer as well as the key stakeholder. Lots of learnings. Unfortunately, none of the users got as far as we had hoped, so we have some work to do. Regarding the disconnect with the stakeholder that we identified last week, we concluded that we were both off in our assumptions about the users. But at least now we have a deeper understanding and it looks like we are on the same page.
– Back at the office we discussed the necessary changes to the prototype. Ended up simplifying the most important scenario, changing the nomenclature, and eliminating some of the more advanced features that we had thought were going to be useful but we now think probably won¹t be used much at all.
Tuesday:
– The lead engineer came back after investigating the high-risk area he identified and while he confirmed that his initial impression was correct, he also came up with something that¹s nearly as good and that he says will be no problem to build, so we¹re adjusting the prototype to reflect the variation. He also verified that the data we thought we needed to collect indeed can be derived from existing data, so this simplifies the prototype even further.
– We took our revised prototype out to another charter customer this afternoon, and tested with three different users. Things went better today than yesterday. At least the users got further. We¹re still not sure we have the right interaction down, but at least the users got through the key tasks. We confirmed that our earlier decision to drop some of the advanced functionality was a good move. Users just aren¹t caring about that. Feeling very good about the value proposition though. Two of the users asked if they could be notified when this product is ready for them to actually use for real.
Wednesday:
– Met with the lead designer and lead engineer to discuss the results so far and next steps. The lead engineer identified yet another optimization of the key flow, and this helped simplify a potentially confusing area that the designer was also working on.
– The lead designer and I met with the visual designer to discuss some initial thoughts we have on the visual design. During the early user testing we have identified that there are two fundamental concepts we must find a way to communicate very clearly to users, and we have identified what we believe are the key states and actions for these concepts. She says she has several ideas that can help communicate these concepts, and reinforce the product¹s value. She says she¹ll bring us some comps in a day or two so we can provide some early feedback.
Thursday:
– We are still trying to get this product definition down to the minimal possible product. We feel confident we have the critical capabilities covered, but there is a very cool features in there still that we¹re not sure is absolutely critical. Our plan is to remove this feature temporarily from the prototype and see what happens in our next tests.
– This afternoon we went to another charter customer and tested with three more users. The usability of the prototype is now pretty decent, but when we removed the cool feature we definitely had a lukewarm response in terms of value, and then we showed the prototype version with the feature and got the excitement we were hoping for. So we feel like that feature truly is critical, and at this point we feel like we¹ve eliminated everything we can and still get people anxious to buy and use the product. Fortunately, we removed much of the advanced user functionality, and simplified the key flows, so the initial time estimates from the lead engineer are still very good.
Friday:
– The lead designer and I met with the visual designer to see the comps, and one of them in particular we really liked. That version is being rolled into the prototype now, with some minor adjustments.
– The lead engineer came back with commit dates based on the current and hopefully final prototype. These dates are well within our budget, and there are no remaining areas the engineers have flagged as especially high risk.
Week 3
Monday:
– Sat down with the stakeholder and showed her the very latest prototype with what we think is the final feature set, including the new visual design, and we discussed the responses so far from the charter users. She is loving it but wants to tag along on this afternoon¹s testing. She also wants to ask some questions to the customer relating to pricing and positioning.
– The lead designer, the stakeholder and I all went to another charter customer this afternoon with what we think is the final prototype, and we tested on four more users. Response was strong no real issues with usability, good response on the functionality/value, and each person told us they are eager to use this for real, and that they would definitely recommend this product to their friends and colleagues.
Tuesday:
– Refined the prototype and captured the key learnings on the project Wiki
– Took the prototype to several stakeholders legal, marketing, the VP product management, and the VP engineering. Several questions, but they love the feedback from the charter customers.
Wednesday:
– Sat down with lead designer and lead engineer and together we agreed on the level of documentation required for engineering, QA and site operations to build, test and deploy this product.
– Split up the documentation work with the lead designer, and we are both adding our sections to the project Wiki, along with links and annotations to the prototype.
These are the ten key points that I hope came across loud and clear:
- Make sure you start with a clear understanding of your objectives (the opportunity assessment).
- Involve your lead designer and lead engineer from the very beginning of product discovery.
- Focus on true collaboration and iteration, rather than sequential written artifacts getting tossed over the wall.
- Get your key ideas into a prototype fast.
- Do everything you can to identify your assumptions, get them out on the table, and figure out quickly which ones are correct and which ones aren¹t.
- Get your prototype in front of target customers early and often fail fast.
- Work to identify the minimal possible product.
- You are not done with discovery until you have identified a product definition that is valuable, usable and feasible.
- Keep your stakeholders updated by showing them your prototype as you progress.
- Don¹t waste your time documenting the details for the engineers until and unless you¹ve figured out the right product.
Again, some projects will take longer with many more iterations, and others may take less. But hopefully you can get a sense that, for example, you should not spend two weeks coming up with a set of written customer requirements, or spend three weeks creating an initial prototype before you put your ideas in front of real users.
There is a real pace and rhythm to product discovery that is based on ideation, prototyping, user testing and most importantly, learning. If you haven’t yet experienced this approach to discovering the product definition, then hopefully this will give you a sense of what it is like, and how different it is from just jumping directly into PRD writing.
