Today we’re digging into an article by @filip_mishevski called 1000 Questions, 1000 Answers. Filip argues that design is about thinking clearly and asking the right questions before you build anything.
The quality of a product depends on the quality of the questions behind it:
When teams skip questions, they guess.
When they ask more questions, they make better decisions and build stronger products.
The more Q&A, the more you move towards something new, something different, something bigger.
You walk through the full life of building products. First, ask if the problem is real. Then ask who the users are and what they need. Then ask how the business wins too. Design comes later. Even after launch, the questions keep going. The work never really ends.
The mindset: questions first
Discovery: are we doing the right thing?
Direction: agree before designing
Organize the work
Design: do the product right
Details and handoff
After launch: did it work?
So here’s the tension worth discussing
In your article, you frame what it means to build products: teams need to slow down just enough to understand what really matters. Questions turn design from guessing into strategy, instead of rushing through tools or chasing the next method.
Here’s my overarching question: Things have been progressing rather quickly over the last year with AI, which puts immense pressure on teams: What questions are we avoiding or skipping right now?
Excited to dig in because Filip Mishevski’s ideas align with how we think about product decisions in Glare. Questions shape signals, which help teams stop guessing and move forward with more confidence. Let’s go!
Excited to chat with you today @filip_mishevski ! Let’s start with your interest in product. Why have you taken such a strong interest in how teams build?
Thanks for having me Bryan. And thanks for that great opening question! I think that how teams build is aligned with the quality of the product (and design) they push live. In addition to that, it impacts the day to day quality of life, engagement and wellbeing of everyone involved tremendously. A good bonus to have
Makes sense. That impact on day-to-day work really shows up fast.
So let’s start with the obvious elephant in the room. Some people are naturally curious. Others just want to jump straight into execution. When a team is wired to move fast and build, how do you create space for questioning without slowing everything down?
Good callout. We have to respect our differences. Personalities wise but also the context where we work. In the article, jokingly I give a small disclaimer in the lines of: don’t get fired because of me and questioning too much. And also, if you need to put out a fire - go ahead and do it. Some situations require quick reactions and operating without answers. I think that he solution in such cases can be to question later - did it work, can we improve it somehow? On the other hand, In my opinion, this does not apply to new and big projects where a reasonable amount of questions have to proceed jumping in and moving fast. This will drastically reduce rework and with that increase speed in the long run.
Right, that makes sense. Especially on larger projects, asking more questions up front often makes teams faster in the long run.
In our project work, I see teams fall into familiar patterns. Some people are naturally better at asking questions, while others want to stick to execution.
Asking questions can feel like something you should already know how to do, which makes it awkward to admit there’s room to improve. Even after 30 years, I still find there’s a lot to learn here. Timing, tone, context, and knowing when to push or pause all matter.
So how do teams help each other get better at asking questions, without making it feel forced or uncomfortable?
Oh yes, those things definitely matter and make a huge difference! We all can improve in this area, it’s a skill. But first thing to master is developing the curiosity. Second one is to become brave enough to speak up / ask.
Having the right mindsets in the team and the right, safe environment definitely helps and it’s a enabler on developing the skills we touched upon above! How to achieve this is a big and complicated question. It can start on the level of a design team, by having good and thorough reviews. These can be reviews of the problem space, even before there is a design to review. Just by doing these reviews, the designer can collect and answer a lot of questions. Those (now refined and polished) questions can be then brought forward to the product teams in an appropriate, not forced way, depending on the setup of the team. It can be either 1-1 with the product owner or in a bigger team setting if there is a ritual for that, such as a refinement.
Just pulling other things from my experience that might be helpful:
having product reviews with representatives from all disciplines
having high standards (or good templates) for Product Requirement Documents
having checklists of questions for certain quality gates
All of the strategies above are ways on how to embed questions in the process. The teams can figure out what works best. Also, this can be arranged on a department / company level and set as a standard.
Love this. Where it gets hard is that layers of questions usually need to trace back to what users are trying to accomplish, from internal concerns to external needs. We’ve been thinking about this in Glare as a way to help teams shape better questions.
In my experience, the most powerful questions connect customer problems to areas where the team actually has visibility and influence. Do you have any suggestions for how teams can stay more user-focused in their questioning?
I think that ideally, the first questions we need to ask are user related. And in cases where it started from a business opportunity or tech capability to bring it back to the user and never skip asking user related questions. The most successful products have a match, a win-win between user and business interests. In short, how to be more user focused… keep starting or coming back to the user.
I would selfishly point back to my article on this one It’s a collection of questions that I assembled from my experience so far. It’s highlights what I think are the key questions in any phase of the design process but also of product development overall. I wanted to make it a sort of a checklist or sheet but didn’t get to do that yet. If there is interest, I might need to prioritise it
Thank you Filip, appreciate you jumping into these questions and inspiring us to invest in our teams. We’ll keep the thread open for others to jump in!
Amazing article, @filip_mishevski! A lot of these relate also to architecture - asking questions are typically key to creating systems that scale, especially in the age of AI.
I’m curious.. Do you ever receive pushback when getting teams to slow down on large projects? What about mid-way inside of the executional phase?
Thanks Ben! Indeed, the questions are relevant to architecture, tech overall and product. It’s a collection of questions we all need to answer as a team. As for your question about push back…
I think there should be a dedicated time for asking questions before we start to embark implementation on a large project. But also for all project sizes, there should be a discovery phase (duration to match the project size) where we are free to list our open questions and hunt for answers. If it’s planned for, I don’t think there will be much push back. Making it part of the process is key imo.
Mid-way, during execution is trickier, and some push back is normal actually. Why are we questioning this? Why now? I think if it’s accounted for and planned like I mention above, we won’t have a lot of questioning and slowing down. At this stage, we have to commit and deliver and cannot re-think everything. What’s also normal though is that sometimes, something can slip through the cracks or we have some new insights or new market conditions which might make us consider slowing down or going back a step. But it all depends on timelines and the context. And the team needs to make a decision to either act on those questions or to park them for a later itteration.
Very insightful! Sometimes I want to question mid-execution, but it makes sense to lock down at times.
What’s interesting, however, is making the executional phases even smaller and purposefully introducing questions through a process. It’s really hard to guess how complex things end up, and a lot of the time it makes sense to “turn the wheel” slightly to navigate properly.
Perhaps there’s also a bias that we always have to consider affecting our decision-making: the Sunk-cost fallacy. Just because we’ve executed up to this point, doesn’t mean it all shouldn’t be burnt to the ground.
Also:
“Plans are nothing; planning is everything.” — Dwight D. Eisenhower
This, this is the way Agree 100%, forgot to mention that strategy.
This bias has sunken a lot of products down to the ground. Thanks for calling it out. It’s good to remind ourselves of it whenever we feel we double down on something that does not fully make sense.
This is a great conversation, and while I love the focus on corporate culture, late-phase pivots, and accounting for time to question; I also wonder how decisions are made, documented, and held to accountability?
Often in meetings a decision will be verbalized, and a matter seems to be closed, but there is no clarity in who is doing what as a next step to get it accomplished within a specific timeframe.
Have been thinking more about how questions are framed in product and design work, and how we should bring them into our Questioning Skills @filip_mishevski.
We’ve had this breakdown below based on a project, but wondering if framing this around a project lifecycle is the right way to think about an AI-driven world? @nikhil_mahen
It’s a collection of questions that I assembled from my experience so far. It’s highlights what I think are the key questions in any phase of the design process but also of product development overall. I wanted to make it a sort of a checklist or sheet but didn’t get to do that yet. If there is interest, I might need to prioritise it 