If you’ve been reading InsideProduct for a while, you’ve probably picked up by now that I focus on solving the right problem and ignoring everything else.
I’ve found that one, or a small series of discovery sessions are an excellent way to identify what that problem is and also understand the constraints you have on your solutions.
So in this issue, I’m going to focus on discovery sessions and explain how you can use them to make sure you’re tackling the right problem and that you have sufficient information to get started on providing the right solution.
If you’ve worked in large enterprises, you probably hear “discovery sessions” and the implication that they happen at the start of a project and wince. Your mind might go to those dysfunctional project kickoffs or months of endless requirements sessions.
I’m not advocating sessions like that. Discovery sessions have a couple of specific purposes:
You establish a broad view of the problem space so that you’re better positioned to do deep dives on specific portions of the solution iteratively.
To break away from the requirements phase paradigm, I’m sharing some descriptions of discovery sessions from the world of development agencies.
These agencies build solutions for their clients and have to bid for every job. They can’t afford to do long drawn out requirements phases, and they need more than cursory information going into a project.
I realize that when you work inside an organization, you probably don’t have to bid for work (although some teams do). That said, some things that agencies do to understand the expected outcome can be very useful for internal product teams. Teams don’t use these practices and approaches nearly as frequently as they should.
Keep an eye out to what you can learn from a different, but related, domain, and think about what you can apply back to your situation.
And as always, if you have questions or thoughts, reply to this email and let me know!
In the software development industry, it’s common for organizations to approach development agencies like the one Johanna Lozano works at with a product they want to create. Sometimes those ideas call for a huge product. Sometimes those ideas call for a fairly small product. Either way, there are still uncertainties such as potential users, the product functionalities, or monetization strategy. These uncertainties make planning and bidding difficult.
Johanna finds it a good practice to bring together different roles to better understand the product idea before embarking on an entire project. A benefit that you get from this phase is that you can define a baseline to compare against. That comparison will tell you if your product is accomplishing everything that was expected of it from the beginning.
In this blog post, Johanna shares what the Discovery process is all about and why it is essential for a successful software development project.
Iryna Korkishko shared Syndicode’s experience with discovery sessions they provide for their new clients. Even if you aren’t planning on working with Syndicode, this explanation can be very helpful if you want to understand what a discovery session is.
Solutelabs used to send proposals and quote a price and never heard from their prospects. As they tried to figure out what was going wrong, they decided they needed to understand their prospect better. One way they did that was to hold discovery meetings with potential clients.
Karan Shah explains why discovery meetings are worth the effort, how these meetings help turn complex ideas simpler, reduce uncertainties and pave the way for a ‘surprise-free,’ productive collaboration.
Wil Brown explains how a discovery session allows you to zoom out and look at the bigger picture before dealing with the nitty-gritty details. It also allows you to understand the business context, operations, audiences and marketing techniques uses allowing you to find value-adds.
Simon Kelly explains that for independent web designers, the way to earn more money and grow your business is to stop talking about deliverables and start talking about outcomes. By focusing on outcomes, you help your client solve the right problem and position yourself as a business consultant.
Simon explains how you can use a discovery session to talk about outcomes. In a discovery session, your job is to guide your prospect / client to understand the business goals behind their projects. To do this, you need to dig deep and ask questions that may be a little awkward. But once you do, you can become a partner in the process and be someone they want to work with.
Thanks again for reading InsideProduct.
If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, just reply to this email.
Talk to you next week,
Kent J. McDonald
Founder | KBP.Media
Hand-picked resources for product owners, business analysts, and product managers working in tech-enabled organizations. Check out the resources I offer below and sign up for my newsletter!
I try not to overuse click bait titles, too much. For this particular topic, however, it was just too tempting. As I mentioned in a previous newsletter, there were several reasons I went to Agile2024 after a six year hiatus. One was to get a sense of the current state of agile. There’s been a bit of chatter about the decline in agile coaching opportunities as well as trends in agile transformations in general. I certainly caught some inklings about what’s going on, but I didn’t want to rush...
I’m back from Agile2024, and it was good to be back after a 6 year hiatus. I caught up with some old friends, made some new acquaintances, and had some great discussions along the way. Some of those discussions will influence future issues of InsideProduct, and others will go down as obnoxiously long running inside jokes. If you're wondering about the latter, ask me about retractable stairs or comic sans the next time you see me. While I’m not going to talk about those topics here, I did want...
For the last few weeks, I’ve explored what prioritization looks like in a variety of different scenarios. This week finished up that series with a look at how you can go about prioritizing a bunch of stakeholder requests. This is a common scenario when you’ve already built software for your company (ie internal product) and you’re trying to optimize or maintain it. A unique aspect for internal products is that most requests for changes come from other people inside your company who may, or...