以客戶理解的方式打造Build with customer empathy

「必要是發明的母親」。"Necessity is the mother of invention." 這個句耳熟能詳諺語會捕捉人類精神的 indelibility,以及我們要創造的自然磁片磁碟機。This proverb captures the indelibility of the human spirit and our natural drive to invent. 如 Oxford 英文字典中所述,「當某個東西的需求變得很重要時,您會被迫找出取得或達成的方式」。As explained in the Oxford English Dictionary, "When the need for something becomes imperative, you're forced to find ways of getting or achieving it." 少數會拒絕這些有關發明的通用真相。Few would deny these universal truths about invention. 不過,如 數位經濟中的創新所述,雲端創新需要發明和採用之間的平衡。However, as described in Innovation in the digital economy, cloud innovation requires a balance between invention and adoption.

從這種比喻開始,創新來自于更擴充的系列。Continuing with the analogy, innovation comes from a more extended family. 客戶的理解是創新的榮幸。Customer empathy is the proud parent of innovation. 建立客戶的創新解決方案來推動創新,需要有合法客戶的需求,才能讓客戶回頭解決重大的挑戰。Creating a customer empathy solution that drives innovation requires a legitimate customer need that keeps the customer coming back to solve critical challenges. 這些解決方案是根據客戶所需的資訊,而不是根據其想要或 whims。These solutions are based on what a customer needs rather than on their wants or whims. 為了找出其真正的需求,我們先從理解開始,深入瞭解客戶的體驗。To find their true needs, we start with empathy, a deep understanding of the customer's experience. 「理解」是許多工程師、產品經理、甚至企業領導人的 underdeveloped 技能。Empathy is an underdeveloped skill for many engineers, product managers, and even business leaders. 幸運的是,雲端架構設計人員角色的多樣性互動和快速步調已開始培養這項技能。Fortunately, the diverse interactions and rapid pace of the cloud architect role have already started fostering this skill.

我們要如何建立更好的理解,為什麼客戶的理解重要性?How do we build empathy, and why is customer empathy so important? 客戶的理解可協助我們瞭解並分享客戶的體驗。Customer empathy helps us understand and share in the experience of the customer. 從最小可行產品的第一版 (MVP) 到市場等級解決方案的正式運作,客戶也會先理解,以協助我們建立更好的解決方案。From the first release of a minimum viable product (MVP) to the general availability of a market-grade solution, customer empathy helps us build a better solution. 更重要的是,它可讓我們更妥善地將鼓勵採用的解決方案定位到。More importantly, it better positions us to invent solutions that will encourage adoption. 在數位經濟中,可最容易體諒前客戶需求的人可以建立更好的未來,以重新定義和領導市場。In a digital economy, those who can most readily empathize with customer needs can build a brighter future that redefines and leads the market.

如何以客戶理解的方式打造How to build with customer empathy

定義假設是規劃的基本部分。Defining assumptions is a fundamental part of planning. 我們所計畫的計畫愈多,我們看到的假設也會蔓延到絕佳概念的基礎。The more we plan, the more we see assumptions creep into the foundation of a great idea. 假設通常是自我理解的產品。Assumptions are typically the product of self-empathy. 換句話說, 如果我在此位置,該怎麼辦?In other words, what would I want if I were in this position? 從組建階段開始,可將假設 invade 方案的期間降至最低。Starting with the build phase minimizes the period in which assumptions can invade a solution. 這種方法也可加速與真實客戶的意見反應迴圈,並觸發先前的機會來學習及銳化理解。This approach also accelerates the feedback loop with real customers, triggering earlier opportunities to learn and sharpen empathy.

警告

正確定義組建的內容可能很棘手,需要一些作法。Properly defining what to build can be tricky and requires some practice. 如果您太快建立了某個東西,可能無法反映客戶的需求。If you build something too quickly, if might not reflect customer needs. 如果您花太多時間來瞭解初始客戶需求和解決方案需求,市場可能會在您有機會建立任何專案之前,先符合這些需求。If you spend too much time trying to understand initial customer needs and solution requirements, the market might meet them before you have a chance to build anything at all. 在任一案例中,學習的機會會大幅延遲或降低。In either scenario, the opportunity to learn can be significantly delayed or reduced. 有時候,資料甚至可能已損毀。Sometimes the data can even be corrupted.

歷程記錄中最創新的解決方案是以直覺的想法開始。The most innovative solutions in history began with an intuitive belief. 這項直覺感覺來自于現有的專業知識和第一手觀察。That gut feeling comes from both existing expertise and firsthand observation. 我們從組建階段開始,因為它可讓您快速測試該直覺。We start with the build phase because it allows for a rapid test of that intuition. 我們可以從該處養成更深入的瞭解,並更清楚的理解程度。From there, we can cultivate deeper understanding and clearer degrees of empathy. 在每個反復專案或每次發行的解決方案中,都是建立 Mvp 來示範客戶的理解。At every iteration or release of a solution, balance comes from building MVPs that demonstrate customer empathy.

為了穩定此平衡動作,下列兩節將討論如何以理解和定義 MVP 來建立的概念。To steady this balancing act, the following two sections discuss the concepts of how to build with empathy and defining an MVP.

定義以客戶為焦點的假設Define a customer focused-hypothesis

以明確的方式建立,根據定義的假設來建立解決方案,以說明特定客戶的需求。Building with empathy means creating a solution based on defined hypotheses that illustrate a specific customer need. 下列步驟的目標是要制訂假設,以鼓勵採用的方式來建立。The following steps aim to formulate a hypothesis that will encourage building with empathy.

  1. 當您以理解的方式建立時,客戶一律是焦點。When you build with empathy, the customer is always the focus. 這種意圖可能需要許多圖形。This intention can take many shapes. 您可以參考客戶原型、特定的角色,甚至是在您想要解決之問題的過程中,提供客戶的圖片。You could reference a customer archetype, a specific persona, or even a picture of a customer in the midst of the problem you want to solve. 請記住,客戶可以是內部 (員工或合作夥伴) 或外部 (消費者或企業客戶) 。And keep in mind that customers can be internal (employees or partners) or external (consumers or business customers). 這項定義是第一個要測試的假設:我們可以協助這個特定的客戶嗎?This definition is the first hypothesis to be tested: can we help this specific customer?
  2. 瞭解客戶體驗。Understand the customer experience. 以易懂的方式建立,您可以與客戶的經驗相關,並瞭解他們的挑戰。Building with empathy means you can relate to the customer's experience and understand their challenges. 這種思維方式表示要測試的下一個假設:我們是否能以這種可管理的挑戰協助此特定客戶?This mindset indicates the next hypothesis to be tested: can we help this specific customer with this manageable challenge?
  3. 為單一挑戰定義簡單的解決方案。Define a simple solution to a single challenge. 依賴人員、流程和主題專家的專業知識,將會導致可能的解決方案。Relying on expertise across people, processes, and subject matter experts will lead to a potential solution. 這是要測試的完整假設:我們是否可以透過建議的解決方案,協助此特定客戶提供這項可管理的挑戰?This is the full hypothesis to be tested: can we help this specific customer with this manageable challenge through the proposed solution?
  4. 抵達值語句。Arrive at a value statement. 您希望為這些客戶提供哪些長期的價值?What long-term value do you hope to provide to these customers? 這個問題的答案會建立您的完整假設:如何使用提議的解決方案解決這項可管理的挑戰,以改善這些客戶的生活?The answer to this question creates your full hypothesis: how will these customers' lives be improved by using the proposed solution to address this manageable challenge?

最後一個步驟是客戶理解導向的假設高潮。This last step is the culmination of a customer empathy-driven hypothesis. 它會定義物件、問題、解決方案,以及要進行改進的度量,而這一切都是在客戶的中心。It defines the audience, the problem, the solution, and the metric by which improvement is to be made, all of which center on the customer. 在量值和學習階段期間,應該測試每個假設。During the measure and learn phases, each hypothesis should be tested. 客戶、問題陳述或解決方案中的變更,會因為團隊針對可定址的客戶群發展出更好的理解而預期。Changes in the customer, problem statement, or solution are anticipated as the team develops greater empathy for the addressable customer base.

警告

其目標是要以客戶理解的方式 建立 ,而不是使用它進行 規劃The goal is to build with customer empathy, not to plan with it. 在完美的客戶理解陳述的規劃和調整迴圈中,這一切都太簡單了。It's all too easy to get stuck in endless cycles of planning and tweaking to hit upon the perfect customer empathy statement. 在您嘗試開發這類語句之前,請先參閱下列各節,以瞭解如何定義和建立 MVP。Before you try to develop such a statement, review the following sections on defining and building an MVP.

在證實核心假設之後,稍後的反復專案會將焦點放在更容易理解的測試以外的成長測試。After core assumptions are proven, later iterations will focus on growth tests in addition to empathy tests. 建立、測試及驗證之後,您就可以開始瞭解大規模市場的規模。After empathy is built, tested, and validated, you can begin to understand the addressable market at scale. 這可以透過擴展稍早所述的標準假設公式來完成。This can be done through an expansion of the standard hypothesis formula described earlier. 根據可用的資料,預估總市場的大小 (潛在客戶) 的數目。Based on available data, estimate the size of the total market (the number of potential customers).

從該處,估計經歷類似挑戰且可能對此解決方案有興趣的總市場百分比。From there, estimate the percentage of that total market that experiences a similar challenge and that might therefore be interested in this solution. 這是您可定址的市場。This is your addressable market. 下一個要測試的假設是:使用建議的解決方案來解決這項可管理的挑戰,將如何改進 x% 的客戶生活?The next hypothesis to be tested is: how will x% of customers' lives be improved by using the proposed solution to address this manageable challenge? 客戶的小型取樣會顯示領先的指標,以建議對參與的客戶集區造成百分比影響。A small sampling of customers will reveal leading indicators that suggest a percentage impact on the pool of customers engaged.

定義解決方案以測試假設Define a solution to test the hypothesis

在 build-measure-學習意見反應迴圈的每個反復專案中,您嘗試以理解方式建立時,是由 MVP 所定義。During each iteration of a build-measure-learn feedback loop, your attempt to build with empathy is defined by an MVP.

MVP 是 (發明、工程、應用程式開發或資料結構所需的最小單位,) 建立足以向 客戶 學習的解決方案。An MVP is the smallest unit of effort (invention, engineering, application development, or data architecture) required to create enough of a solution to learn with the customer. 每位 MVP 的目標是要測試部分或所有先前的假設,並直接從客戶收到意見反應。The goal of every MVP is to test some or all of the prior hypotheses and to receive feedback directly from the customer. 輸出不是美觀的應用程式,具有變更產業所需的所有功能。The output is not a beautiful application with all the features required to change your industry. 每個反復專案的所需輸出是學習機會,有機會更深入測試假設。The desired output of each iteration is a learning opportunity, a chance to more deeply test a hypothesis.

Timeboxing 是確保產品保持精簡的標準方式。Timeboxing is a standard way to make sure a product remains lean. 例如,請確定您的開發小組認為解決方案可以在單一反復專案中建立,以允許快速測試。For example, make sure your development team thinks the solution can be created in a single iteration to allow for rapid testing. 若要進一步瞭解使用速度、反復專案和版本來定義最小的意義,請參閱 規劃速度、反復專案、發行和反復專案路徑To better understand using velocity, iterations, and releases to define what minimal means, see Planning velocity, iterations, release, and iteration paths.

降低複雜性並延遲技術尖峰Reduce complexity and delay technical spikes

在「創新」方法中找到的發明專業領域,會說明傳遞成熟的創新或已就緒的 MVP 解決方案所需的功能。The disciplines of invention found in the Innovate methodology describe the functionality that's often required to deliver a mature innovation or scale-ready MVP solution. 使用這些專業領域作為功能納入的長期指南。Use these disciplines as a long-term guide for feature inclusion. 同樣地,您也能在及早測試客戶價值和解決解決方案的過程中,使用它們作為警告性指南。Likewise, use them as a cautionary guide during early testing of customer value and empathy in your solution.

功能廣度和發明的不同專業領域無法在單一反復專案中建立。Feature breadth and the different disciplines of invention can't all be created in a single iteration. MVP 解決方案可能需要數個版本,以包含多個專業領域的複雜度。It might take several releases for an MVP solution to include the complexity of multiple disciplines. 根據開發的投資,可能會有多個平行團隊在不同的專業領域內運作,以測試多個假設。Depending on the investment in development, there might be multiple parallel teams working within different disciplines to test multiple hypotheses. 雖然可以在這些小組之間保持架構的一致性,但造成嘗試建立複雜的整合式解決方案,直到可以驗證值假設為止。Although it's smart to maintain architectural alignment between those teams, it's unwise to try to build complex, integrated solutions until value hypotheses can be validated.

最適合在 技術尖峰 的頻率或數量中偵測到複雜度。Complexity is best detected in the frequency or volume of technical spikes. 技術尖峰是為了建立無法輕鬆測試客戶的技術解決方案。Technical spikes are efforts to create technical solutions that can't be easily tested with customers. 當客戶價值和客戶理解未經過測試時,技術尖峰就代表創新的風險,應該將其最小化。When customer value and customer empathy are untested, technical spikes represent a risk to innovation and should be minimized. 針對在遷移工作中發現的成熟測試解決方案,技術尖峰可能會在採用期間很普遍。For the types of mature tested solutions found in a migration effort, technical spikes can be common throughout adoption. 不過,它們會延遲測試假設的測試,而且應該盡可能延後。However, they delay the testing of hypotheses in innovation efforts and should be postponed whenever possible.

針對任何 MVP 定義,建議使用一種非常簡化的方法。A relentless simplification approach is suggested for any MVP definition. 這種方法表示移除任何未加入您驗證假設的功能。This approach means removing anything that doesn't add to your ability to validate the hypothesis. 若要將複雜性降至最低,請減少測試假設所需的整合和功能數目。To minimize complexity, reduce the number of integrations and features that aren't required to test the hypothesis.

打造 MVPBuild an MVP

在每個反復專案中,MVP 解決方案可以採用許多不同的圖形。At each iteration, an MVP solution can take many different shapes. 常見的需求是,輸出可進行假設的測量和測試。The common requirement is only that the output allows for measurement and testing of the hypothesis. 這項簡單的需求會起始科學流程,並讓小組以理解的方式打造。This simple requirement initiates the scientific process and allows the team to build with empathy. 為了提供此客戶優先的焦點,初始 MVP 可能只依賴發明的其中一個 專業領域To deliver this customer-first focus, an initial MVP might rely on only one of the disciplines of invention.

在某些情況下,創新的最快途徑表示暫時避免這些專業領域,直到雲端採用小組確信已正確驗證假設為止。In some cases, the fastest path to innovation means temporarily avoiding these disciplines entirely, until the cloud adoption team is confident that the hypothesis has been accurately validated. 來自 Microsoft 這類技術公司,本指南可能會違反直覺。Coming from a technology company like Microsoft, this guidance might sound counterintuitive. 但是,這只是為了強調客戶的需求,而不是特定的技術決策,是 MVP 解決方案中最高的優先順序。However, this simply emphasizes that customer needs, not a specific technology decision, are the highest priority in an MVP solution.

MVP 解決方案通常是由簡單的應用程式或資料解決方案所組成,其中包含最少的功能和有限的波蘭文。Typically, an MVP solution consists of a simple application or data solution with minimal features and limited polish. 對於具有專業開發專業知識的組織來說,此路徑通常是最快學習和反復專案的途徑。For organizations that have professional development expertise, this path is often the fastest one to learning and iteration. 下列清單包含小組建立 MVP 時可能採取的其他數種方法:The following list includes several other approaches a team might take to build an MVP:

  • 一種預測演算法,此演算法的99% 時間錯誤,但會示範特定的預期結果。A predictive algorithm that's wrong 99 percent of the time but that demonstrates specific desired outcomes.
  • IoT 裝置不會在生產環境中安全地進行通訊,而是示範進程內幾乎即時資料的價值。An IoT device that doesn't communicate securely at production scale but that demonstrates the value of nearly real-time data within a process.
  • 公民開發人員所建立的應用程式,用來測試假設或符合較小規模的需求。An application built by a citizen developer to test a hypothesis or meet smaller-scale needs.
  • 重新建立應用程式所需遵循之優點的手動程式。A manual process that re-creates the benefits of the application to follow.
  • 詳細說明的線框或影片,可讓客戶進行互動。A wireframe or video that's detailed enough to allow the customer to interact.

開發 MVP 不需要大量的開發投資。Developing an MVP shouldn't require massive amounts of development investment. 建議您最好盡可能地限制投資,以將一次測試的假設數目降到最低。Preferably, investment should be as constrained as possible to minimize the number of hypotheses being tested at one time. 然後,在每個反復專案及每個版本中,都會刻意針對表示多個發明專業領域的擴充性解決方案來改善解決方案。Then, in each iteration and with each release, the solution is intentionally improved toward a scale-ready solution that represents multiple disciplines of invention.

加速 MVP 開發Accelerate MVP development

上市時間對於任何創新的成功都很重要。Time to market is crucial to the success of any innovation. 更快速的發行可加快學習速度。Faster releases lead to faster learning. 更快速的學習會導致能更快擴充的產品。Faster learning leads to products that can scale more quickly. 有時候,傳統的應用程式開發週期可能會使此程式變慢。At times, traditional application development cycles can slow this process. 更頻繁地來說,創新受限於可用的專業知識。More frequently, innovation is constrained by limits on available expertise. 員工的預算、員工和可用性都可以對小組可以處理的新創新數量產生限制。Budgets, headcount, and availability of staff can all create limits to the number of new innovations a team can handle.

人力限制和想要以理解的方式打造,為公民開發人員產生快速成長的趨勢。Staffing constraints and the desire to build with empathy have spawned a rapidly growing trend toward citizen developers. 這些開發人員可降低風險,並在組織的專業開發小組內提供規模。These developers reduce risk and provide scale within an organization's professional development community. 公民開發人員是客戶經驗所關注的主題專家,但他們並不是以工程師的形式定型。Citizen developers are subject matter experts where the customer experience is concerned, but they're not trained as engineers. 這些個人使用原型工具或較輕量的開發工具,這些工具可能由專業開發人員 frowned。These individuals use prototyping tools or lighter-weight development tools that might be frowned upon by professional developers. 這些與商務一致的開發人員會建立 MVP 解決方案和測試理論。These business-aligned developers create MVP solutions and test theories. 當對齊時,此程式可以建立提供價值的生產解決方案,但不會傳遞夠有效的規模假設。When aligned well, this process can create production solutions that provide value but don't pass a sufficiently effective scale hypothesis. 它們也可以用來在開始調整規模之前驗證原型。They can also be used to validate a prototype before scale efforts begin.

在任何創新方案中,雲端採用小組應 [多樣化其組合,以包含公民開發人員工作。Within any innovate plan, cloud adoption teams should diversify their portfolios to include citizen developer efforts. 藉由調整開發工作,可在較低的投資中形成更多假設並進行測試。By scaling development efforts, more hypotheses can be formed and tested at a reduced investment. 當某個假設經過驗證併發現可定址的市場時,專業開發人員就可以使用新式開發工具來強化及調整解決方案。When a hypothesis is validated and an addressable market is identified, professional developers can harden and scale the solution by using modern development tools.

最終組建閘道:客戶難題Final build gate: Customer pain

當客戶理解的是強式時,顯然存在的問題應該很容易識別。When customer empathy is strong, a clearly existing problem should be easy to identify. 客戶的難題應該很明顯。The customer's pain should be obvious. 在組建期間,雲端採用小組正在建立解決方案,以根據客戶痛點測試假設。During build, the cloud adoption team is building a solution to test a hypothesis based on a customer pain point. 如果假設是妥善定義的,但痛點不是,則解決方案並非真正根據客戶的理解。If the hypothesis is well-defined but the pain point is not, the solution is not truly based on customer empathy. 在此案例中,build 不是正確的起點。In this scenario, build is not the right starting point. 相反地,請先投資,並從真實客戶學習並學習。Instead, invest first in building empathy and learning from real customers. 建立理解與驗證難題的最佳方法很簡單:聆聽您的客戶。The best approach for building empathy and validating pain is simple: listen to your customers. 花點時間開會並觀察它們,直到您能找出經常發生的難題。Invest time in meeting with and observing them until you can identify a pain point that occurs frequently. 當您清楚瞭解問題之後,就可以開始測試假設解決方案來解決這個難題。After the pain point is well-understood, you're ready to test a hypothesized solution for addressing that pain.

不套用此方法的時機When not to apply this approach

有許多法律、合規性和產業需求可能需要採用替代方法。There are many legal, compliance, and industry requirements that might necessitate an alternate approach. 如果開發解決方案的公開版本建立了專利時間、智慧財產權保護、客戶資料流程失或違反既定合規性需求的風險,則這種方法可能不適用。If public releases of a developing solution create risk to patent timing, intellectual property protection, customer data leaks, or violation of established compliance requirements, this approach might not be suitable. 如果發現這類的風險存在,請先洽詢法律顧問,再採用任何發行管理的引導式方式。When perceived risks like these exist, consult legal counsel before adopting any guided approach to release management.

參考資料References

本文中的一些概念是以 Eric Ries 的「精簡啟動」所 討論的主題為基礎。Some of the concepts in this article build on topics discussed in The Lean Startup by Eric Ries.

下一步Next steps

建立 MVP 解決方案之後,您可以測量出理解的價值和規模值。After you've built an MVP solution, you can measure the empathy value and scale value. 瞭解如何 測量客戶的影響Learn how to measure for customer impact.