In our line of work, which you can often hear summarized as developing custom web and mobile applications for clients, there’s a number of sales channels through which new potential projects arrive. Whether it’s by word of mouth, conference networking, direct inquiries, email, an official tender, there’s one thing in common – the specification is either non-existent or very very high-level. Quite often we even get an elaborate document on which our potential clients want us to base our budget estimate on. However, when you distil the information on those pages you’re left with very little actual substance.

This is why I like to refer to these inquiries as project ideas. They are quite often the result of some problems the client is experiencing in their day-to-day business. It can be anything from relying too much on paper documents, doing things manually which can be automated, all the way to recognizing an opportunity that a digital platform could seize. Also, most of our clients are not very tech savvy and it’s not unusual that the idea they came up with doesn’t optimally achieve their goals. They are often not familiar with the possibilities of custom digital solutions, which leads to them asking for overly complex solutions to simple problems.

That’s the reason why I think the critical component for making great software solutions (instead of good ones) is the ability to problem-solve – to effectively inspect, analyze, reconstruct and optimize the client’s idea.

We’re not here just to be code monkeys clicking away predetermined blueprints. The real value of hiring an agency for custom development is the years of accumulated experience they gained working in many different business domains.

The first step we take when we’re approached by a client is to arrange a Discovery workshop. It’s one of the tools we use to actually question the client’s idea or specification. The goal of this workshop is to find out the problems we need to solve, or even better, the value we need to deliver to our clients. We try not to focus on the proposed software solution that much – for that we have later steps such as big picture EventStorming workshops, ux workshops, creating wireframes etc. Here we try to gain insight into the actual process our client wants to digitalize.

The proper question to ask here is “Why are we developing this application?”, not “What are we developing?”. In the very first step we take, we start learning about the business domain we’re going to be working in, which enables us to better understand the problems the client is facing. Once we know what the real problems are we can start creating a solution together with our clients. Our team had the privilege of working on so many different projects, from a B2B fish market, cycling marathon ticketing system, fashion webshops, protein sequencing AI platform, tourism multisites, retail webshops etc. All of these applications required problem-solving and coming up with custom solutions to new problems. All of these applications also came to us as (on the surface) simple project ideas so we had to figure out a way of getting relevant information in a relatively short amount of time from a business domain we’re usually not that familiar with. That’s when we decided to do the Discovery workshop. In this blog, I’ll try to explain our version, especially the project management aspect of it. My dear colleague Petra, who’s our UX analyst, will follow up this blog post with actual tools and practices we implement in these workshops in much more detail.

The first step is to schedule a video call with our client (used to be an actual in-person meeting) where we generally discuss their ideas and problems without a set format. We do this to start a conversation, get familiar with the tasks at hand and try to get a feel of the problem our client needs to solve. Based on these meeting minutes we prepare a small survey to set up our Discovery Workshop. The questions we use are still quite general, but we’re trying to put our client in a frame of mind where they’re thinking about the underlying problems and reasons they want the software, not how it should look like. For example – What is the main reason you’re looking into developing this solution? How do you think this new system will improve your current situation? What’s the most frustrating thing for you (or your customers) right now? What do you want to achieve in the next 6 months/1 year?

The Discovery Workshop

Before we delve deeper into the actual mechanics of the workshop there’s some setup needed. I’ll leave the details of the actual tools and materials to Petra, and focus on the moderator aspect. Here are some tricks we use to achieve certain goals:

Encourage activity -> remove all chairs from the room, make sure each member has his marker, set of post-it notes etc.
Include all participants -> make sure that you point out to your client that all levels of stakeholders should be involved in the workshop. We need as much insight as possible
Visibility -> have enough space in front of the board for everyone to be able to walk by and see the notes
Hospitality -> this probably goes without saying but prepare food and drinks as these sessions can get quite lengthy. Also, avoid greasy snacks 🙂

Here’s how we begin our workshop – we first set up a board with the same questions as from the survey we sent, and we group the answers we collected into post-it notes and stick them up on the board for everyone to see. The point is to review all answers one by one, with all present participants. This is especially important if the surveys were filled individually and the participants weren’t aware of each other’s answers. Usually, it’s the first point in the workshop when the post-it notes will be reached for. If the participants don’t have experience with these kinds of workshops, they’ll probably start talking to you directly instead of writing on the board. Remind them to write down their comment and post it on the wall.

Next up we focus on the problem areas. We’re still trying to keep focus on actual issues each sector (or team) has, rather than talking about the solution. If you manage to gather all roles involved in the business process affected by these issues, each participant will probably have a somewhat different perspective, and maybe even opposing priorities on what needs to be done to improve things. For example, someone working at the cash register might say the current system is too slow and needs too many clicks to perform simple actions, another participant from accounting might say that the reports are not delivered in real time etc. Make sure everyone has a say and feels free to comment – each group will have more vocal and dominant members who are used to talking in front of people and easily express their opinion. Here you can use brainstorming techniques where you ask everyone to take 5-10 minutes to write down what they think and post it on the wall once they’re done. After a while, you’ll notice some notes are similar or belong to the same domain. Group them if possible.

Now that we have categorized our post it notes, what we like to do is create user personas on the spot. They can be fictional characters, actual people, or even avatars of the participants. The goal is to focus on the specific perspective of each of these roles in the business process. What motivates them, what causes issues in their everyday workflow, what can be easily improved… Ask the participant who is most familiar with the role at hand to describe their usual day at work – use sticky notes to create a flow and point out main issues.

If you followed the steps laid out so far you can see that we gathered a lot of information about what actually bothers the client, which issues are the most important to solve, we even figured out different roles that will be included (or affected) by the software solution we’re supposed to build. Here’s the point at which we start talking about the general project idea and what can be done to solve these issues. We tend to use the user story mapping technique where the goal is to create a dynamic frame of interactions and requirements different user roles have. If there’s not enough information yet to be able to come up with user stories for the software, we will do a rough list of different modules and features that the system will need to have. It’s important to point out that the actual scope and specification will be developed in a later set of meetings such as eventstorming, wireframing, user testing etc. This is a broad overview of the software that needs to be developed based on the project idea, which is now viewed differently after all of the created feedback.

Finally, after we have listed our user stories (or features), it’s time to prioritize and highlight the parts that will bring the most business value to our clients. I suggest combining this step with the user personas to see which features only benefit one role, and which are overlapping and bringing value across the board.

This concludes our version of the Discovery Workshop. There are other activities that we sometimes include, depending on the complexity of the project at hand, such as defining a product vision in combination with an elevator pitch exercise. We always keep these things modular and sometimes even adjust the workshop schedule on-the-fly depending on the reaction/feedback we’re getting from our client. After the workshop ends, you still need to finish the deliverables which should summarize everything that was learned during the Discovery, list the user personas we created and show the user stories map. The only rule we keep here is less text and more substance 🙂

To finish this blog post off, here are some general tips:

Take pictures of each board (especially if you’re changing it for each section)
If possible record the meeting, or at least have one member write things down
Remember to take breaks
Do a short retrospective on the workshop with your team afterwards
Ask the client for feedback after a couple of days
Always motivate the group to participate – you don’t want them shouting opinions at the board while you’re writing all of the notes

Hope this was interesting and helpful. Now I’ll hand you over to my colleague Petra for a more hands-on approach.

Results for tag #project

Product Discovery from the Project Management point of view