4 ms·
Have you spent time with all of them around the table and thinking about their needs and problems, not features? In my experience, if you're not careful during
by Jugurtha 6y ago
Have you spent time with all of them around the table and thinking about their needs and problems, not features?
In my experience, if you're not careful during the early product design phase, people will spit out features or their solution/implementation. One has to snap out of it and figure out the reasons of these. They want a button, you must ask why and figure out the job to be done.
Second, from all the 'features' which you figured out the problems for, what is common between the two (users and decision makers)? Is there a core/common set you can extract ?
Third: you can sort of layer specific features of one and the other on top of the core, if there is a core, and propose two products. Depending the budget.
Lastly, it may be frustrating, but ultimately: who is paying you? If you're doing consulting, you may provide input but the one who pays you have the last word. Get your input and their explicit decision to go a certain route in writing, and do what they ask of you.
I wrote a tiny bit about this here https://mobile.twitter.com/jugurthahadjar/status/1310668293305499653 https://mobile.twitter.com/jugurthahadjar/status/13106682933...
Again, spend time on problems and unearthing the underlying problems that the features they propose are solutions/implementations to. Don't let the product driven by feature proposition.
- arvindpurdue123 6y agoThank you for that insight. Your product looks interesting. Still doing early access?
- Jugurtha 6y agoYou're welcome. We also are careful to include problem and rationale in our own product internally. When one of us wants a feature or one of our data scientists asks for a feature "I want a button to click and do X", we ask "what are you trying to accomplish?" and focus on the job to be done. People naturally go for solutions/implementations and we can be completely oblivious that the solutions we propose are a result of our knowledge or lack of knowledge. Here's our issue template for features to lower the barrier to write good issues: <!--These are comments and will not be rendered. Please click Preview to check.--> ### Description ---------------- <!--Describe the problem we'll solve. What, where, when, who, why, and how.--> ### Target ---------- <!--Who's the target audience? Who'll enjoy this the most or suffering from lacking this feature the most? Is this a problem you have? Have you talked with other people who have this problem? Is it something that would just be cool? Is it a seed for an idea that can be cool? --> ### Instances ------------- <!--If the problem has happened multiple times, can you describe them--> ### Proposal ------------ <!--What is the plan to solve this problem? Can we guess a solution or have a hunch? Do we have a list of steps? It's okay if they are a bit vague for now. We'll clarify by debating them and adding context to them, reading more about the subject. It's essential to understand that this document serves to capture thoughts and externalize thought processes so we can all tackle the problem more effectively. --> ### Resources ------------- <!--Do you recommend any reading to do about this? Maybe a video to watch for something similar? Maybe a blog post or documentation pages or just a snippet? An image, mock-ups, etc... --> /label ~feature /cc @XX @XY @XZ >Your product looks interesting. Still doing early access? Yes. Here's an invite link if you'd like to try it: https://iko.ai/invite/terXtLhraD1hPx2Gw16EgUAHMy98mWqq2vlm9MPEbQY https://iko.ai/invite/terXtLhraD1hPx2Gw16EgUAHMy98mWqq2vlm9M...