脑裂问题解决方案_从解决方案到问题

脑裂问题解决方案

Once upon a time a couple of years ago, one of my mentors (and favourite people in the world) repeatedly drilled the idea above into my brain. Her advice for Product people was to “fall in love with the problem, not the solution”. At the time, I stubbornly went along with it without understanding the importance of this one principle. I had always thought that technology products were the result of great solution skills. I wasn’t wrong, I was just missing the pre-requisite steps—a solution is only as valuable as the problem it solves.

几年前，我的一位导师(以及世界上最喜欢的人)反复地将上述想法深入我的大脑。 她对产品人员的建议是“爱上问题，而不是解决方案”。 当时，我固执地接受了这一原则，却不了解这一原则的重要性。 我一直认为技术产品是出色解决方案技能的结果。 我没看错，只是错过了必要的步骤- 解决方案仅与解决的问题一样有价值。

What I didn’t see at the time was what this paradigm really boils down to. It means adopting a founder’s mindset—listening instead of simply hearing, having empathy in the face of challenging situations, and obsessing over the root of a problem. Some of the most noteworthy founders in recent history have attributed their company’s successes to pure customer obsession—labouring over what pains their customers are facing, what those problems mean for their broader business, and what is valuable to them in a solution?

当时我没有看到的是这种范式真正归结为什么。 这意味着要采用创始人的思维方式，即聆听而不是简单地聆听，在充满挑战的情况下具有同理心，并且迷恋问题的根源。 近期历史上一些最著名的创始人将其公司的成功归因于纯粹的客户痴迷-为客户所面临的痛苦，这些问题对他们更广泛的业务意味着什么以及对他们的解决方案有何价值而感到苦恼？

The funny part about this is that outside of these entrepreneurial scenarios, a lot of us in the real world spend way too much time focusing purely on solutions. We’re expected to provide solutions to anything and everything with immediacy. This may be in part due to the mass consumerization of technology, where gratification is almost immediate. This causes us to glance over the problem we’re “solutioning” for, often skipping the essential steps of truly understanding it. I probably don’t have to tell you the outcome: sub-optimal solutions.

有趣的是，在这些创业场景之外，我们现实世界中的许多人都花了太多时间纯粹专注于解决方案。 我们希望立即为所有问题提供解决方案。 这可能部分是由于技术的大规模消费化，而满足感几乎是立竿见影的。 这使我们瞥了一眼我们正在“解决”的问题，经常跳过真正理解它的基本步骤。 我可能不必告诉您结果：次优解决方案。

“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and five minutes thinking about solutions.” — someone, somewhere

“如果我有一个小时来解决问题，我将花55分钟思考问题，花5分钟思考解决方案。” -某人，某处

There’s a quote that’s been circulating, often attributed to Albert Einstein although unproven, that succinctly breaks down how we should solve problems. Whether or not this was spoken by Einstein is not important, but the underlying premise is completely valid and aligns with a founder’s mindset. The more accurately we can define a problem, the more likely we are to find a great solution.

有句话一直在流传，尽管没有得到证实，但通常被归因于阿尔伯特·爱因斯坦(Albert Einstein)，这简明扼要地打破了我们应该如何解决问题的方法。 爱因斯坦是否讲过这句话并不重要，但是其前提是完全有效的，并且与创始人的思维方式保持一致。 我们越能准确地定义问题，就越有可能找到一个好的解决方案。

It’s also important to note here that I’m not criticizing bringing solutions to the table – everyone knows that if you’re planning to raise an issue, it's 10x more valuable to come prepared with some idea of how to fix it. I’m not downplaying this, I’m simply stating that if you’re going to do so, you best be very intimate with the problem.

同样重要的是，在这里我并不是在批评将解决方案摆在桌面上，每个人都知道，如果您打算提出一个问题，那么准备如何解决这个问题的价值将提高十倍。 我并没有对此轻描淡写，只是说明如果您要这样做，则最好对这个问题非常了解。

Myself, I’ve been focusing almost exclusively on solutions for a while now, working to create patterns of perceived “common” challenges and developing blueprints that apply cookie-cutter solutions to those patterns. This was purpose-driven: we did this in an effort to increase velocity. If a customer came to us with a need, we would offer the closest solution we had available. Our mantra was “if it walks like a duck and quacks like a duck…” — but in reality, the problems weren’t always ducks, and we weren’t truly solving them.

就我自己而言，一段时间以来，我几乎一直专注于解决方案，致力于创建可感知的“常见”挑战的模式，并制定将cookie-cutter解决方案应用于这些模式的蓝图。 这是出于目标驱动：我们这样做是为了提高速度。 如果有客户需要我们，我们将提供最接近的解决方案。 我们的口头禅是“如果它走路像鸭子一样，而嘎嘎像鸭子一样……” –但实际上，问题并不总是鸭子 ，而且我们并没有真正解决它们。

Recently, I’ve undergone a shift in the role I’m playing. My goal is no longer to find solutions using what is readily available, quickly generating revenue and closing the door on challenges. Instead, I have the opportunity to focus purely on listening to the problems of customers and the broader market, taking the time to truly understand what is required of a solution. With such a change in work, I’m forced to shift gears mentally. Here, I will share some of the lessons learned while adopting the founder’s mindset and undergoing the paradigm shift from solution-orientation to problem-orientation.

最近，我所扮演的角色发生了变化。 我的目标不再是使用现成的解决方案寻找解决方案，快速产生收入并应对挑战。 相反，我有机会纯粹专注于倾听客户和整个市场的问题，花时间真正地了解解决方案的要求。 有了这样的工作变化，我不得不在精神上换档。 在这里，我将分享在采用创始人的思维方式并经历从解决方案导向到问题导向的范式转变时吸取的一些教训。

隔间化和其他组织思想的方式 (Compartmentalization and other ways to organize your thoughts)

If you’re moving into product-focused work, the number one recommendation I have is to adopt and use a framework (it can be loose — don’t let my use of “framework” scare you away). Without this to guide you, you’ll likely spiral into uncontrollable chaos rather quickly. Adopting a framework allows you to compartmentalize your backlog of problems to solve – mentally placing them within buckets. It’s really easy to revert back to brainstorming a solution before you fully understand the problem at hand, which is why it is important to ensure everything flows through the steps of your framework.

如果您要从事以产品为中心的工作，那么我的首要建议是采用并使用一个框架(它可能很松散-不要让我对“框架”的使用吓到您了)。 没有这个指导，您很可能很快就会陷入无法控制的混乱之中。 采用框架可以让您将待解决的问题隔离开来–将问题从精神上放在桶中。 在完全理解手头的问题之前，回到头脑风暴的解决方案真的很容易，这就是为什么确保所有内容流经框架步骤很重要的原因。

I liken this concept to an assembly line, where you set yourself up with a steady flow of problems, challenges, gaps, or ideas. Before they get to a solution stage, they must pass through a number of assembly steps. These steps are the phases of your framework.

我将此概念比喻为装配线，在这里您可以不断遇到问题，挑战，差距或想法。 在进入解决方案阶段之前，他们必须经过许多组装步骤。 这些步骤是框架的各个阶段。

A mental Kanban for Problems to Solve

解决问题的精神看板

This logical separation allows you to keep track of what is in early discovery, what’s ready for ideation, and what can move on to solution delivery. Naturally, you’ll get better at asking the right questions for various problems depending on the stage in which they’re in.

通过这种逻辑上的分离，您可以跟踪早期发现的内容，准备好进行构想的内容以及可以继续进行解决方案交付的内容。 自然地，您会根据所处的阶段，更好地针对各种问题提出正确的问题。

An objection to this you may hear is that it sounds like “Waterfall in disguise”, or that it is not Agile. Please do not confuse this with Waterfall or another linear process. The intention is to be working on an assortment of problems at any given time – all in various stages. I am not suggesting you should simply gather requirements for one feature and blindly march forward until you’ve kicked something out the door 2 years later.

您可能会对此提出异议，听起来像是“变相瀑布”，或者说它不是敏捷的。 请不要将此与Waterfall或其他线性过程混淆。 目的是在任何给定的时间-在各个阶段都致力于解决各种问题。 我不建议您只收集一项功能的要求，然后盲目前进，直到两年后您将某物踢出门。

A half-decent discovery process

半体面的发现过程

One thing to remember is that “Big A” Agile doesn’t create great products alone. When I say to build a framework, I am certainly not suggesting that you simply adopt Scrum and be done with it. Agility, if anything, has led to a breakdown in how we approach problems. Somewhere along the way we stopped caring about the discovery and started focusing on delivery, because “working software” is better than nothing. Maybe some of us never cared about the discovery, to begin with.

要记住的一件事是，“ Big A”敏捷开发并不能独自创造出出色的产品。 当我说要构建框架时，我当然不建议您只是采用Scrum并完成它。 敏捷性(如果有的话)导致我们处理问题的方式崩溃。 在此过程中，我们不再关心发现，而是开始关注交付，因为“有效的软件”总比没有好。 首先，也许我们当中有些人从不关心发现。

The “working software is better than nothing” principle is true, but also inherently flawed because it fails to mention the critical work before a single line of code is written. The key takeaway here is that “working software” is only valid if it’s solving a problem for someone. Finding the balance for the right amount of discovery versus delivery is both an art and a science.

“工作软件总比没有好”的原则是正确的，但也存在固有的缺陷，因为它在编写一行代码之前就没有提到关键的工作。 这里的主要结论是，“正在运行的软件”仅在为某人解决问题时才有效。 在适当数量的发现与交付之间找到平衡，既是一门艺术，也是一门科学。

Personally, I doubt copying a single framework “by the book” works in most organizations. I think it’s important to utilize principles and philosophies from different schools of thought throughout your product discovery and delivery process. You may research and test using Design Thinking, Lean Startup, Scrum, XP — but in the end, you will likely end up with elements of each of these in your framework.

就个人而言，我怀疑“按书”复制单个框架是否适用于大多数组织。 我认为在整个产品发现和交付过程中利用不同流派的原理和哲学很重要。 您可以使用“设计思维”，“精益创业”，“ Scrum”，“ XP”进行研究和测试-但最后，您可能最终会在框架中找到其中每一个的元素。

Next, we’ll walk through the high-level stages of iterative discovery.

接下来，我们将遍历迭代发现的高级阶段。

理解永远是一个好的第一步 (Understanding is always a good first step)

So, you have a structure, now what? Successful problem solving comes down to empathy and framing — and this is often a good place to start. You may already have some level of understanding of where to focus your efforts. But if not, what are the inputs or events that will trigger the discovery exercise?

那么，您有一个结构，现在呢？ 成功解决问题归结为共情和框架化 ，这通常是一个很好的起点。 您可能已经对将精力集中在什么地方有了一定程度的了解。 但是，如果不是，将触发发现活动的输入或事件是什么？

Typically, these can vary based on your organization’s maturity and what channels are available for your customers to voice their feedback. Here are some good places to begin:

通常，这些因素可能会根据您组织的成熟度以及客户可以使用哪些渠道表达他们的反馈意见而有所不同。 这里是一些不错的起点：

• Trending requests by customers and prospects to your Sales and Success teams.
  客户和潜在客户对您的销售和成功团队的趋势要求。
• Ideas sourced from a user group, community, or customer forum.
  来自用户组，社区或客户论坛的想法。
• Common RFx questions or requirements from prospects.
  潜在客户常见的RFx问题或要求。
• Help-desk and support ticket data about common challenges.
  有关常见挑战的服务台和支持故障单数据。
• Post-mortem analysis of lost prospects and/or churned customers.
  潜在客户和/或客户流失后的事后分析。
• Continuous feedback via surveys like NPS.
  通过诸如NPS之类的调查获得持续反馈。

With information like this available, you can begin to focus your discovery. A non-trivial amount of time should be spent in front of customers and users, listening to their challenges, and framing them in a way that’s consumable for your stakeholders.

有了类似的可用信息，您就可以着重发现。 应该花费大量的时间在客户和用户面前，倾听他们的挑战，并以对您的涉众有用的方式来构架它们。

If you come from a circle that deals with traditional “projects”, you may think this sounds synonymous with big planning upfront. You’re both right and wrong. This isn’t a typical “plan”, but failing to plan is often planning to fail. There should be some level of strategic thought put into the problems you choose to tackle, and this data simply helps with your prioritization.

如果您来自一个处理传统“项目”的圈子，您可能会认为这听起来像是预先规划的代名词。 你是对是错。 这不是典型的“计划”，但是没有计划通常就是计划失败 。 您选择要解决的问题应该有一定程度的战略思想，而这些数据只会帮助您确定优先级。

翻译迷失 (Lost in Translation)

Keeping in mind the initial channels of input we’ve covered above, you may need to do some translation. Because our user community isn’t exposed to our discovery process 100% of the time — customers and other stakeholders may have become accustomed to making demands. That’s why we often hear things like “build X” or “design feature that does Y” rather than “help me solve challenge Z”.

请记住我们上面介绍的初始输入渠道，您可能需要进行一些翻译。 因为我们的用户社区没有100％的时间接触我们的发现过程，所以客户和其他利益相关者可能已经习惯了提出要求。 这就是为什么我们经常听到诸如“构建X”或“具有Y的设计特征”而不是“帮助我解决挑战Z”之类的原因的原因。

This is also because customers are great at imagining what they think they want — but really bad at actually knowing what they need. Herein lies the incredibly important step of problem validation. I won’t get into the tactical details, but problem validation can be summed up as translating inputs like “build X” into well-defined and clearly articulated problems, which are validated with the same people who suggested them. And I can’t stress the importance of actual human interaction with your user base through customer interviews, not simply sending out a mass survey.

这也是因为客户有很大的想象在他们认为他们想要的-但实际上不知道他们需要什么非常糟糕。 这就是问题验证中极为重要的一步。 我不会详细介绍战术细节，但问题确认可以归纳为将“ build X”之类的输入转换为定义明确且明确表达的问题，并由提出建议的同一人进行验证。 而且，我不能通过与客户的访谈，而不是简单地进行大规模调查来强调与用户群进行实际人机 交互的重要性。

Take a moment to reflect on your own language as well; this is also important. The terminology used to describe your work, and to describe how you work, can heavily influence the success of the work itself. You’ll want to ensure that when you are customer-facing and trying to validate a problem, that the message you’re sharing resonates across various audiences.

花一点时间思考一下自己的语言； 这也很重要。 该术语用来描述你的工作，并说明你是如何工作的，可以严重影响作品本身的成功。 您将要确保当您面对客户并尝试验证问题时，您共享的消息会在各个受众之间引起共鸣。

I’ve found writing a glossary to be a useful exercise. You can use this as a tool for translating your product vernacular into simple terms that your customers and other stakeholders will understand — a lingua franca for problem-solving if you will.

我发现写词汇表是一个有用的练习。 您可以使用它作为一种工具，将您的产品转换为客户和其他利益相关者可以理解的简单术语-一种通用的语言，可以解决您的问题。

有很多方法可以产生一个好主意 (There are many ways to generate a good idea)

We have a well-defined problem that’s been validated with a segment of the market. So how might we help alleviate this problem? We’re at a level of understanding where we can confidently begin to dial in on potential solutions. And that exact question is actually a great one to pose when kicking off your ideation phase.

我们有一个定义明确的问题，已经在部分市场得到验证。 那么，我们如何帮助减轻这个问题呢？ 我们处于了解的水平，可以自信地开始使用潜在的解决方案。 在开始构想阶段时，这个确切的问题实际上是一个很好的问题。

Regardless of whether or not you have access to a design team to back you up, I find there are two very different and equally good ways to come up with ideas for solutions. You should aim to exercise a combination of both. The first is done completely alone, or with a very small group. In this method, you can deeply focus on what you know already about the problem, and write various ideas that you come up with.

无论您是否有权与设计团队联系，我都会找到两种非常不同且同样不错的方法来提出解决方案的想法。 您应该将两者结合起来。 第一个完全由一个人完成，或由一个小组完成。 通过这种方法，您可以深入关注已经对​​问题了解的内容，并写下各种想法。

The second method is to leverage a larger, more diverse set of stakeholders in order to collaboratively bring ideas to the table. This method can take the shape of a facilitated workshop or an informal discussion between colleagues. Either way, different perspectives will shed light on things you may not have picked up in your discovery, and others’ previous experiences will generally strengthen the group’s ideas. It also allows you to see what assumptions are made by those who are not intimately familiar with the problem space.

第二种方法是利用更大，更多样化的利益相关者集合，以协作将想法提出来。 这种方法可以采用便利的研讨会或同事之间的非正式讨论的形式。 无论哪种方式，不同的观点都会阐明您可能没有发现的事物，而其他人的先前经验通常会增强小组的想法。 它还使您可以查看那些不十分了解问题空间的人所做的假设。

Being the more creative and fluid phase of the overall discovery journey, I don’t believe there is necessarily a “right or wrong way” to approach ideation. I do not think it matters which method is used first, as long as you’re not doing all the work yourself. The input from others will help validate your ideas, and their ideas will challenge yours in a healthy way. This may even lead you to circle back to a previous stage.

作为整个发现过程中更具创造性和流动性的阶段，我认为不一定存在“正确或错误的方式”来进行构想。 我不认为首先使用哪种方法并不重要，只要您自己不做所有工作即可。 他人的意见将有助于验证您的想法，他们的想法将以健康的方式挑战您的想法。 这甚至可能导致您回到上一个阶段。

Ideation can and sometimes should be an iterative sub-process

构想可以并且有时应该是一个迭代的子过程

Finally, is good to keep a finger on the pulse of your discovery process. Even during a creative process like ideation, it doesn’t hurt to continually ask a few other key questions to yourself throughout this phase, in order to keep yourself from veering too far off target.

最后，最好能随时掌握发现过程的脉动。 即使在诸如构想之类的创造性过程中，在此阶段中不断向您提出其他一些关键问题也不会有任何伤害，以免您偏离目标太远。

• Are these ideas aligned with our organization’s vision and goals?
  这些想法是否符合我们组织的愿景和目标？
• Do we know if these ideas are conceptually viable? What barriers exist?
  我们知道这些想法在概念上是否可行？ 存在哪些障碍？
• Are we certain that this idea is solving the original problem for the right market?
  我们确定这个想法正在解决正确市场的原始问题吗？

If you’ve found this interesting, I encourage you to follow along. In the next part of this story about adopting a founder’s mindset, we will dive into prototyping & experiments, product delivery, and post-launch enablement.

如果您觉得这很有趣，建议您继续学习。 在关于采用创始人思维方式的故事的下一部分中，我们将深入研究原型和实验，产品交付以及发布后的实现。

翻译自: https://medium.com/swlh/from-solutions-to-problems-5c5bc09a4e1c

脑裂问题解决方案