Changing direction is cheapest before the first line of code

A product workshop is a series of sessions with the team after which it is clear which problem needs solving, for whom, and what matters most. At Squares it has four steps: gathering context, the workshop itself, setting priorities and writing up the conclusions. It is also called a discovery workshop or product discovery, and it takes place before design and development.

A product workshop has a fixed price agreed before any work starts. The figure depends on the number of topics and the number of participants, which is why we give it after a first call about the scope. Once accepted, the price does not change, and the initial quote is not a commitment to work together.

A product workshop takes 1-2 weeks, depending on the topic. In that time we gather information about the business, the users and the constraints, run sessions with the team and write up the conclusions. The workshop sessions take up part of that period; the rest is preparation before the sessions and work on the final document.

The outcome of a product workshop is a document with the scope, the decisions and the next step. It records what to build, what not to build and in what order, and the delivery team can estimate the work from it. In the Daily Effect app project, the findings from workshops and event storming were turned into requirements and the scope of the first version of the product.

A product workshop is worth running before a new product, a major feature or a redesign, when there are many ideas and departments pull in different directions. It also makes sense when the idea or design already exists: we then validate it and set priorities before the build starts. When a single specific decision needs settling, Consulting is enough.

A product workshop sets scope and priorities, a Design sprint tests one solution on a prototype, and a UX/UI audit assesses a product that is already live. The workshop ends with a document, the sprint with a tested prototype and a recommendation, and the audit with a report and an improvement roadmap. The workshop is the choice when there is no agreement yet on what to build.

A meeting ends with notes; a product workshop ends with decisions and a scope of work. Preparation makes the difference: before the session we gather facts about the business, the users and the constraints, and afterwards we rank the ideas by importance. The decisions stay in writing, so they can be revisited when the build is estimated.

The workshop requires the product team and people from the departments affected by the decision to take part, plus information about the business, the goal, the users and the constraints. We gather that information before the session so the workshop starts from facts. The number of participants affects the price, so we agree the line-up on the first call.

Yes, we run workshops remotely or on site, for teams in Poland and abroad. The pompy.app comparison site project began with on-site workshops. Product plans and company data come up in the sessions, so a light NDA is signed before the workshop, and a framework agreement is available for further work.

After the workshop the team has a scope on which a build estimate can be based. In the Diagnosis, Design, Development, Optimisation process the workshop belongs to Diagnosis, and the next step is Prototype & MVP or UX/UI design. The agreed scope can be designed and built by the same Squares team, or handed to the client's team.