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.

我將此概念比喻為裝配線，在這里您可以不斷遇到問題，挑戰，差距或想法。 在進入解決方案階段之前，他們必須經過許多組裝步驟。 這些步驟是框架的各個階段。

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或其他線性過程混淆。 目的是在任何給定的時間-在各個階段都致力于解決各種問題。 我不建議您只收集一項功能的要求，然后盲目前進，直到兩年后您將某物踢出門。

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.

作為整個發現過程中更具創造性和流動性的階段，我認為不一定存在“正確或錯誤的方式”來進行構想。 我不認為首先使用哪種方法并不重要，只要您自己不做所有工作即可。 他人的意見將有助于驗證您的想法，他們的想法將以健康的方式挑戰您的想法。 這甚至可能導致您回到上一個階段。

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.

如果您覺得這很有趣，建議您繼續學習。 在關于采用創始人思維方式的故事的下一部分中，我們將深入研究原型和實驗，產品交付以及發布后的實現。