KHỞI NGHIỆP 17_ANH VIỆT

Thiết kế sản phẩm phần cứng

Lecture 17 - How to Design Hardware Products (Hosain Rahman)

KHỞI NGHIỆP 17:

Rất vui, cảm ơn Sam, vì đã mời tôi. Sam và tôi biết nhau từ rất lâu rồ, vì chúng tôi cùng làm ở Sequoia. Chúng tôi gặp nhau ngay từ những ngày đầu, khi cậu ấy vừa bắt đầu hành trình, và điều đó thật tuyệt. Và điều mà cậu ấy bảo tôi nói hôm nay là sơ lược về hành trình làm sản phẩm phần cứng. Vậy điều tôi muốn làm ở đây là cho bạn thấy tổng quan về Jawbone.

Chúng tôi làm gì? Chúng tôi nghĩ gì? Và chúng tôi làm sản phẩm như thế nào? Rồi sau đó nói cụ thể vào quy trình thiết kế, quy trình phát triển, và kết hợp mọi thứ lại với nhau. Và những điều chúng tôi đã làm để thay đổi cả ngành. Vậy... Trước tiên, tôi luôn bắt đầu với tư duy rộng nhất, và quan điểm của chúng tôi về thế giới.

Chúng tôi tự xem mình là sự giao thoa giữa đột phá về kỹ thuật gia công mà người dùng gần như không thể thấy, khi xét về mặt chức năng. Và sự giao thoa đó không chỉ là thiết kế. Chúng tôi đã thiết kế sản phẩm hơn chục năm nay. Chúng tôi hướng đến việc vượt lên thiết kế để chuyển thành cái đẹp. Đó là sự giao thoa giữa kỹ thuật gia công và cái đẹp, và cốt lõi là để giúp mọi người sống tốt hơn bằng công nghệ.

Và nói chung, chúng ta đang sống trong một thế giới mà tất cả mọi người đều đang nói đến "Internet of Things". Chúng tôi đã hoạt động từ rất lâu trước khi có thuật ngữ đó. Chúng tôi đã nghĩ về việc những thiết bị thông minh với sức mạnh điện toán và kết nối có gắn cảm biến để đo lường tất cả mọi thứ. Chúng sẽ kết nối không dây với nhau, và tương tác với bạn.

Chúng tôi đã bắt đầu từ rất rất sớm, thực ra là ngay ở trường kỹ thuật ở đây. Chúng tôi đã phát triển những công nghệ cốt lõi, và làm sản phẩm tiêu dùng dựa trên đó. Sản phẩm tiêu dùng đầu tiên của chúng tôi là tai nghe. Chúng tôi tạo ra một tai nghe như một máy tính "đeo được". Đó là tai nghe Jawbone đầu tiên.

Đó là khi chúng tôi bắt đầu nghĩ về điện toán "đeo được". Sau đó chúng tôi phát minh ra loa không dây bằng âm thanh Bluetooth, và tôi sẽ nói một chút về chuyện đó. Và gần đây nhất, chúng tôi tập trung vào cuộc cách mạng thiết bị y tế đeo được, có sử dụng rất nhiều cảm biến trong tai nghe đời đầu của chúng tôi, ứng dụng chúng lên các bộ phận cơ thể khác nhau để hiểu hơn về người dùng.

Vậy tầm nhìn của chúng tôi về thế giới đã có từ lâu, và trông có vẻ lộn xộn. Đây là "Internet of Things". Chúng tôi nghĩ mọi thứ đều sẽ thông minh và kết nối với nhau, và có app hỗ trợ cho nó. Không có nghĩa là người dùng sẽ thấy dễ dàng hơn, đúng chứ? Lò vi sóng, tủ lạnh, xe hơi, máy Xbox, máy Xfinity, Comcast,...

mọi thứ đều có app. Và không giao tiếp với nhau. Nó khiến người dùng bị rối. Chúng tôi thấy rằng có một nhu cầu rất lớn về việc tổ chức lại tất cả những thứ này. Và đây là điều cốt lõi khi chúng tôi nghĩ về cách thức phát triển, và những cơ hội để làm sản phẩm. Chúng tôi nghĩ về tương lai của thế giới. Vậy..

nếu thế giới mà mọi người sẽ nói với nhau về Internet of Things thực sự thành hiện thực, bạn sẽ cực kỳ cần những nguyên tắc sắp xếp này để giúp người dùng dễ hiểu hơn về cách sử dụng và tương tác với các dịch vụ này. Chúng tôi nghĩ cần tư duy lại, chuyển trọng tâm từ từng sản phẩm sang thành từng người dùng. Và cuối cùng, mọi người đều nói về thiết bị đeo được và những thứ như Google Glass và bạn có những sản phẩm của chúng tôi, và Apple Watch và đủ thứ.

Cuối cùng, chúng tôi tin rằng khi bạn mang những thứ này trên người 24/7, chúng sẽ trở thành một cỗ máy xử lý bối cảnh tương tác với tất cả mọi thứ xung quanh bạn. Khi tôi không mang điện thoại thì có áo khoác, hoặc khi có thiết bị cần sạc, tôi vẫn mang máy "Up", và nó hiểu chuyện gì đang diễn ra với tôi. Nó đo nhịp tim tôi, theo dõi hô hấp của tôi, và theo dõi nhiều thứ khác nữa.

Khi nói "cỗ máy bối cảnh", tôi có cảm biến nhiệt độ thông minh là máy Nest để biết tôi đang nóng hay lạnh. Thiết bị này không hiểu tường tận, vì tôi bảo nó là tôi nóng, thì nó không biết tôi nóng do bệnh, hay do chạy bộ, hay do trời nóng. Bạn có thể nói với xe hơi là bạn buồn ngủ, hoặc xúc động, hoặc bực bội.

Vậy chúng tôi nghĩ thế giới đang đi đến viễn cảnh như thế, và các thiết bị đeo được sẽ là trung tâm của cuộc cách mạng khi mọi thứ đều thông minh và kết nối, và làm nảy sinh rất nhiều tương tác và phương thức làm việc với nhau. Vậy đó là nền tảng đầu tiên khi chúng tôi bắt đầu nghĩ về viễn cảnh của thế giới và những thứ mà chúng tôi nên phát triển, và làm sao để nghiên cứu những ngành mới.

Vậy để tầm nhìn đó thật sự được hiện thực hóa, bạn sẽ phải làm tốt gần như mọi việc, mà chúng tôi gọi là "full stack". Chúng tôi phải làm phần cứng thật xuất sắc, và cả trải nghiệm phần cứng của người dùng theo thời gian. Vì bạn sẽ mang chúng 24/7. Nếu không làm được, thì mọi thứ mà tôi nói chỉ là ảo tưởng mà thôi.

Bạn không thể tạo ra một dịch vụ thu hút được mọi người, hoặc lấy được nhiều dữ liệu dùng cho những thứ khác, nếu không bắt đầu từ một phần cứng tốt. Nên chúng tôi bắt đầu từ đó. Chúng tôi cố gắng phát triển những trải nghiệm tuyệt vời về phần cứng với sự hỗ trợ tuyệt đối của phần mềm. Chúng tôi phát triển những ứng dụng phần mềm đẳng cấp thế giới.

Chúng tôi cũng phải xuất sắc trong việc kích thích cộng đồng như kiểu Instagram hay Whatsapp. Rồi về mặt dữ liệu, chúng tôi phải biết làm gì với đống thông tin khổng lồ đó, xử lý nó và bắt nó phải phục vụ trở lại cho người dùng. Nên chúng tôi tự xem mình là sự giao thoa, vì lần đầu tiên có một công ty làm cả ba vừa phần cứng, phần mềm, và dữ liệu và kết hợp 3 thứ này với nhau một cách cân bằng để mở ra những trải nghiệm cho những thứ mà bạn đeo, để nhận biết mọi thứ, và giao tiếp với tất cả thế giới xung quanh bạn.

Và đó là trọng tâm của chúng tôi. Tôi nghĩ đó là điều khác biệt đới với các công ty khác. Việc đó đòi hỏi chúng tôi phải làm tốt ở tất cả các khâu. Và đây là một việc khá phức tạp khi kết hợp lại với nhau. Vì thường thì những ai giỏi phần cứng sẽ rất thông thạo về kỹ thuật cơ khí, kỹ thuật điện tử, cách mọi thứ tương tác với nhau, làm sao quy mô hóa, làm sao làm công cụ, vân vân...

Nhưng họ thường không giỏi trong phần mềm và dịch vụ. Đó là một mảng rất khác và cần những kỹ năng rất khác. Nên khi kết hợp tất cả lại với nhau, đã dẫn tới rất nhiều rạn nứt thú vị trong công ty. Đội ngũ phần mềm và ứng dụng đã quen làm việc thật nhanh rồi hoàn thiện. Trong khi với phần cứng, bạn phải dành nhiều thời gian và vòng lặp hoàn thiện cần phải tỉ mỉ hơn.

Bạn phải tốn đến 16 tuần. Không thể rút ngắn, không thể đốt cháy giai đoạn. Và điều thú vị là khi kết hợp tất cả lại với nhau, đội phần cứng phải học cách làm nhanh hơn, đội phần mềm thì nghĩ nhiều hơn về trải nghiệm trước khi thực sự thực hiện thay vì cứ tung ra rồi chạy AB testing rồi thu thập dữ liệu các kiểu để dựa vào thông tin rồi mới đưa ra các quyết định khác nhau.

Vậy, chúng tôi nghĩ gì về cách thực hiện, cách làm sản phẩm, và thay đổi toàn ngành? Trước hết với chúng tôi, mọi thứ đều là hệ thống. Chúng tôi xem xét từng mảng như một phần cứng riêng, một ứng dụng riêng, hay một nền tảng riêng biệt. Chúng tôi nghĩ về tất cả một cách xuyên suốt, ví dụ như Up, một sản phẩm có nhiều cảm biến theo dõi trên cơ thể cùng với giải thuật.

Nó kết nối với điện thoại bằng ứng dụng có trải nghiệm thú vị. Dùng cả cảm biến trên điện thoại, để giao tiếp với nhiều thứ khác trên mây, nơi chúng tôi tập trung dữ liệu, rồi khai thác dữ liệu trên đó, và có cả nền tảng khổng lồ với hàng ngàn nhà phát triển, với hàng ngàn ứng dụng để tạo ra nhiều trải nghiệm tốt hơn.

Nghĩa là chúng tôi tư duy trên toàn bộ hệ thống, và tôi sẽ trở lại vấn đề này sau. Vậy quy trình sáng tạo thực sự trông thế nào? Thật thú vị vì chúng tôi không thường nói về điều này lắm. Kiểu như chúng tôi giữ bí mật và riêng tư, nhưng giờ thì chúng ta đang nói chuyện kiểu như có thể phát sóng khắp nơi. Nên khá thú vị vì đây là lần đầu tiên.

Và đây chưa hẳn là một quy trình chính xác nhé. Và quy trình đó đại khái trông thế này. Đây là bản đồ từ lúc chúng tôi tự do tưởng tượng trong giai đoạn khám phá, tới giai đoạn đánh giá các ý tưởng, rồi giúp các ý tưởng này càng lúc càng chặt chẽ hơn, đến lúc chúng tôi thực sự làm sản phẩm, tung ra, rồi hoàn thiện.

Đây là cách nhìn đơn giản nhất. Tôi sẽ dẫn bạn qua từng bước một. Ví dụ như trong giai đoạn khám phá, rất tự do. Thỏa sức tưởng tượng. Chúng tôi hình dung thế giới sẽ đi về đâu, chiến lược là gì, thương hiệu đại diện cho điều gì. Và chúng tôi nghĩ về những điều mà các bạn ở đây cũng nghĩ. Bạn ước mơ, bạn tưởng tượng, làm sao bức phá, tương lai sẽ trông thế nào?

Đôi khi nói giống kiểu dự án khoa học, và chúng tôi cũng thảo luận theo kiểu đó. Chúng tôi đi lên từ cảm hứng và sự thấu hiểu. Và đó là sự sáng tạo thô. Chúng tôi hình thành một thứ tương đối ổn vì nhiều lúc trong công ty, mọi người bị lạc lối. Rồi sau đó đánh giá sơ bộ, tôi sẽ nói: "Xem này mọi người, khi làm việc này, bạn phải trình bày những ý tưởng này như kiểu bảo vệ luận án tiến sĩ vậy đó, được chứ?

Tức là phải có kết luận, phải có thu thập dữ liệu, và bạn phải nói rõ bạn thấy xu hướng sẽ thế này, chúng ta cần làm những việc này... Và bạn phác thảo nên viễn cảnh đó." Và khi bạn đã chốt xong giai đoạn đó, và nếu chúng tôi nghĩ lý thuyết này đúng, chúng tối ẽ vào giai đoạn ý tưởng để thực sự suy nghĩ về trải nghiệm sẽ thế nào và điều gì là khả thi?

Và đây là một cơ hội thú vị để tạo ra đột phá ở một cấp độ cụ thể hơn về sự tác động của sản phẩm lên cuộc sống, hoặc nó là gì, làm sao bán trải nghiệm đó, và làm sao kể câu chuyện đó. Rồi chúng tôi chốt chương trình, và bắt đầu lên kế hoạch chi tiết, rồi nhìn vào đó và nói: "Rồi, chúng ta sẽ làm, và làm tới cùng.

Không còn đường lùi nữa, được chứ?" Cần phải đánh đổi điều gì giữa sáng tạo và ý tưởng với các giới hạn vật lý? Có vấn đề gì với thời lượng pin, hoặc bất kỳ giới hạn nào khác, và bắt đầu đánh đổi, và bắt đầu hình dung cách kết hợp tất cả lại với nhau. Sau đó chuyển tới giai đoạn phát triển. Có rất nhiều đoạn chuyển giao giữa các giai đoạn.

Và rất nhiều đội ngũ trong công ty cần cộng tác với nhau và bạn sẽ giải quyết các vấn đề khi thực hiện việc này. Và bạn tung ra, rồi tìm hiểu xem người dùng nghĩ gì. Và bạn bắt đầu xem xét vị trí của nó trong thế giới trải nghiệm mà bạn đã hình dung là thế giới đang hướng đến. Chúng ta đã làm được gì, chưa được gì?

Chúng ta học được gì từ người dùng? Điều đó có tác động gì tới chúng ta? Và chúng ta thử lại lần nữa, đúng chứ? Vậy đó là cách tổng quan nhất để xem xét vấn đề. Sâu hơn một chút về giai đoạn khám phá nhé. Nó rất giống với một quá trình xây và sửa, đúng chứ? Và phần lớn việc đó được điều khiển bởi "Thứ sáu trình diễn", nơi mọi người đều có cơ hội trình diễn thành quả của họ.

Vì chúng tôi thấy rằng đó là cách tuyệt vời để kết hợp với nhau, trình bày nó để mọi người hiểu được và đóng góp ý kiến. Và nó thực sự là một quy trình trình diễn và phản hồi. Dĩ nhiên nó phải làm nhanh kiểu hack-a-thon và dựa trên dữ liệu. Và được chỉ đạo bởi phòng chiến lược, mà cách truyền thống mọi người thường gọi là phòng R&D.

Trong đó có sự tham gia của cả nhóm sản phẩm và kỹ thuật về cả phần cứng và phần mềm, nhưng họ sẽ khá buông lỏng để xem những khám phá này là gì. Và đội điều hành của công ty lúc này sẽ thiên về phản biện hơn. Họ sẽ chỉ ra phản biện và góp ý, hỏi mọi người xem đã nghĩ tới điều này chưa, đã thử việc nọ chưa, việc kia thế nào, vân vân...

Vậy trong giai đoạn này, để có thể tiến tới ngưỡng tiếp theo, chúng tôi phải suy nghĩ theo kiểu: "Xem nào, mình có chịu cho cậu này 50K không? Theo kiểu đầu tư thiên thần ấy? Liệu mình có chịu bỏ 50K để cậu ấy nghiên cứu thứ này và xem liệu có gì hay ho có thể làm được không?" Và CTO của chúng tôi sẽ là người quyết định cuối cùng.

Cậu ấy sẽ chọn những thứ này trong nội bộ, và nói: "Tôi hứng thú với tất cả các ý tưởng này. Nhưng đây là thứ tôi muốn theo đến cùng xem điều gì xảy ra." Sau đó đến giai đoạn đánh giá, và đây là lúc mọi thứ bắt đầu thú vị. Vẫn chỉ đạo bởi phòng R&D, nhưng họ sẽ thực sự hỏi sâu hơn về cách nó hoạt động.

Chúng tôi họp với lãnh đạo của tất cả các nhóm, và tôi phải cho thấy kết quả. Tôi nêu ra một quy trình khoa học chứng minh tại sao thứ này sẽ thành công, tại sao nó sẽ xuất hiện, và bạn sẽ lắng nghe. Đây là lúc chúng tôi bắt đầu tạo ra những công cụ quan trọng để sử dụng trong công ty, mà chúng tôi gọi là "những lý do".

Xác định lý do tại sao chúng tôi làm? Tại sao nó tồn tại? Nó giải quyết vấn đề gì? Lát nữa tôi sẽ nói sâu hơn về điều đó, được chứ? Vào lúc này, nhóm R&D vẫn chỉ đạo. Nhưng bây giờ rất nhiều người trong nhóm thiết kế công nghiệp, như Bahar và nhiều người làm dự án nữa. Họ vào cuộc và bắt đầu nghĩ về việc làm sao để đưa ý tưởng này trở thành một phần cứng thực tế, và làm sao để nó tương tác với toàn bộ hệ thống còn lại?

Đội trải nghiệm sản phẩm vẫn quyết định nhiều giá trị cốt lõi, và câu chuyện sẽ kể. Nhưng nó bắt đầu thực tế hơn rất nhiều, và đây là lúc chúng tôi bắt đầu nghĩ xem phải thực hiện như thế nào? Kiểu như nó sẽ tốn bao nhiêu, ngân sách là bao nhiêu, vân vân.. Vào lúc này, chúng tôi bắt đầu đánh giá xem có thể thực sự khả thi không?

Hoặc phải chờ 3 năm nữa để pin được hoàn thiện, hoặc phải chờ một đột phá khác diễn ra trước, hoặc phải chờ ngân sách, hoặc bất kỳ thứ gì khác. Có thị trường cho nó không? Và chúng tôi phải phác họa mọi thứ thật ngắn gọn. Và đây là lúc tôi vào cuộc, và đưa ra quyết định cuối cùng, rằng tôi nghĩ việc này thực sự có tiềm năng.

Chúng ta có thể đưa nó lên tầm cao mới, và hiện thực hóa nó. Rồi chúng tôi vào giai đoạn ý tưởng. Đây là lúc trách nhiệm chuyển giao từ đội R&D sang đội trải nghiệm sản phẩm. Và cách chúng tôi nghĩ về trải nghiệm sản phẩm trong Jawbone cũng giống như cách mọi người nghĩ về thiết kế thông thường. Từ thiết kế công nghiệp, đến thiết kế phần mềm, đến thiết kế âm thanh, mọi thứ đều liên quan tới trải nghiệm.

Chúng tôi những cây bút, những người kể chuyện, những người giàu ý tưởng như Eve, một thiên tài sáng tạo. Chúng tôi có những nhà thiết kế tài ba với app, với đồ họa, và mọi thứ. Đội trải nghiệm sản phẩm là đội tất-cả-trong-một. Và nhiệm vụ của họ là kiểu như biến các hạt thành nguyên tử và ngược lại, để thống nhất cả tổ chức thành một thể.

Và đó lúc họ tiếp quản và bắt đầu thực sự bắt tay vào thực hiện, và chúng tôi gọi đó là thời điểm thực thi các lý do. Tức là xem cái gì khả thi. Có rất nhiều sáng kiến và đột phá đang được thực hiện để xây dựng và phát triển một sản phẩm. Chúng tôi đặt câu hỏi: Điều quan trọng nhất trong sản phẩm đó là gì?

Đâu là vấn đề quan trọng nhất cần giải quyết? Và đó là "người hùng" trong trải nghiệm. Chúng tôi cần làm gì? Tiêu chuẩn chấp nhận được là gì? Vân vân... Lúc này chúng tôi phải trả lời được những câu hỏi "tại sao" này, và lát nữa tôi sẽ cho bạn xem lại. Và tại sao nó lại khác biệt với các sản phẩm khác so với các đối thủ trong cùng ngành?

Rồi sao đó thì sao, làm gì nữa? Chúng tôi không thể chỉ nhìn một thứ mà tầm nhìn phải rộng hơn. Và một phần trong việc tạo ra trải nghiệm là nhìn ra xu hướng của thế giới, và làm sao để sản phẩm này trở thành cây đinh trong tầm nhìn tối thượng đó. Đó là lúc lộ trình dần được hình thành. Và lúc này tôi có thể vào cuộc và đưa ra quyết định cuối cùng cho cả đội, và nói: "Rồi, sang giai đoạn tiếp theo thôi."

Và đây cũng là lúc chúng tôi xem xét những vấn đề này. Và bây giờ tôi sẽ nói về một ví dụ cụ thể về một chương trình đi đường tắt. Ví dụ như với Jambox trong giai đoạn này, chúng tôi nói: Chúng ta có thể bỏ qua giai đoạn này, chuyển thẳng qua giai đoạn phát triển luôn. Vì chúng tôi muốn thử nghiệm và thương mại hóa nó nhanh nhất.

Vậy, chúng tôi có thể linh hoạt trong quy trình và quyết định tiến hành và thực hiện thật nhanh, đi tắt luôn, rồi điều chỉnh tương thích với thị trường sau. Vào giai đoạn này, nó được chuyển từ đội trải nghiệm sản phẩm sang đội quản lý sản phẩm, là những người sẽ lên kế hoạch kinh doanh. Khi nào ra mắt? khi nào đưa vào hệ thống bán lẻ?

Thời gian vòng lặp cập nhật phần mềm là bao lâu? Ra bản thử nghiệm để thực sự cảm nhận nó, và bắt đầu thực hiện những thứ gọi là đánh đổi. Kiểu như: Chúng ta muốn làm cái này, nhưng không thể làm cái kia, đây là cái có thể làm... Chúng ta muốn làm kiểu này, chúng ta muốn trải nghiệm chức năng này, chúng ta sẽ phải hy sinh thời lượng pin.

Bất kể nó là gì, đây là lúc chúng tôi gom những quyết định này lại và thực sự xem xét. Và lúc đó thực sự giống như chơi trò tung hứng vậy. Và đội sản phẩm sẽ quản lý việc này. Lần nữa, đây là lúc chúng tôi xem xét và đồng bộ tất cả mọi thứ đã gom lại với nhau, và nói: "Okay, đã gạch bỏ đủ nhiều trong danh sách đó chưa?

Đã đạt tới yêu cầu tối thiếu đó chưa? Vì chúng tôi thường bắt đầu với một danh sách dài những thứ khả thi và chúng tôi làm được, rồi sau đó bắt đầu lược bỏ dần, và hỏi "Đã chắt lọc đủ đến ngưỡng giá trị mà chúng ta nghĩ rằng nó đáng để theo đuổi chưa?" Vào lúc này, chúng tôi sẽ chuyển sang giai đoạn phát triển, và đội quản lý sản phẩm sẽ tiếp tục chỉ đạo, nhưng bạn thực sự bắt đầu đi sâu hơn.

Và đây là nơi lúc đội kỹ thuật vào cuộc, và thực sự quyết định: "Rồi, cái này làm được. Lịch trình và thời hạn là thế này." Và lần nữa, đội sản phẩm sẽ xác định xem làm sao chúng tôi đi sâu hơn, làm sao tăng sự tham gia với ít đột phá nhất, hoặc ít tinh chỉnh nhất? Chúng tôi phải làm gì để làm được điều đó?

Một trong những điều chúng tôi may mắn có được là rất phản hồi tuyệt vời đối với sản phẩm của chúng tôi. Và chúng tôi dành rất nhiều thời gian và tâm huyết trong việc phát triển và giai đoạn ý tưởng, cho từng chi tiết nhỏ để tạo ra trải nghiệm thần kỳ đó. Một ví dụ là chúng tôi làm Jambox, chúng tôi đã thiết kế âm thanh khá tuyệt, mà phải tốn hàng tháng trời cho việc tinh chỉnh âm thanh.

Chúng tôi làm việc với rất nhiều chuyên gia để tạo ra âm thanh đó, nhưng mỗi lần có ai bật lên, tôi thấy họ cười, họ tâm đắc. Cảm giác của bản thử nghiệm bằng cao su, mà chỉ có một nhà sản xuất duy nhất trên thế giới làm được loại cao su với chất lượng, độ cứng, và màu sắc mà chúng tôi muốn cho chiếc Jambox đầu tiên.

Tất cả những chi tiết nhỏ như vậy, kể cả trong phần mềm. Với chiếc máy UP đầu tiên, khi cắm vào, biểu đồ giấc ngủ hiện lên, ngay cả diễn hoạt cách xuất hiện của những cột thông tin và cách những tấm thẻ bay vào, bay ra. Đó là những chi tiết nhỏ mà bạn sẽ tương tác, người dùng sẽ trải nghiệm nó, họ sẽ cảm thấy thế nào?

Cả đống chi tiết như vậy vẫn diễn ra ngay cả khi bạn đã chốt chương trình xong. Bạ sẽ phải ra những quyết định này xuyên suốt cả quá trình, và phải đánh đổi, và bạn phải đặt nó vào trong một bức tranh lớn hơn. Và tiếp tục đột phá để có thể liên tục hoàn thiện, liên tục làm những việc đó. Vậy bây giờ chúng tôi phải suy nghĩ ở một cấp độ tổng quan hơn, khung làm việc cho những trải nghiệm đặc trưng ở đây là gì?

Vâng, chúng tôi bắt đầu với "tại sao". Chúng là bản lề cho vấn đề mà chúng tôi đang giải quyết. Sau đó là làm sao đưa chúng thành những khái niệm có thể hành động được? Tiếp đó là xây dựng những thứ tạo khác biệt (POD) liên quan tới các mảng gồm một người của đội trải nghiệm sản phẩm, một người của đội phần cứng, một người của đội phần mềm, một người của đội dữ liệu, gom lại với nhau thành một nhóm.

Đây là những điểm khác biệt theo chủ đề trước đó. Rồi họ tiếp tục xây dựng các tính năng phụ trợ, và tính năng bên trong, rồi kết hợp tất cả lại với nhau. Giờ tôi sẽ nói cụ thể hơn về những thứ mà chúng tôi gọi là "tại sao", vì tôi dành rất nhiều thời gian cho câu hỏi này. Nó đóng vai trò một khung làm việc thú vị để chúng tôi có thể quay lại và nói: "Này, chúng ta đã trả lời được chưa?

Sản phẩm này đã là đáp án chưa?" Và nó cũng đóng vai trò hướng dẫn cho sáng tạo của chúng tôi và rất nhiều đột phá khác, nên không thể bỏ qua được. Và cô đọng lại thì nó chỉ là một câu hỏi đơn giản như thế này: Vấn đề nào của người dùng có thể được giải quyết qua trải nghiệm này, dù là phần cứng, phần mềm, dữ liệu, nền tảng, hay bất kỳ thứ gì?

Một khi đã giải quyết thì người ta không sống thiếu nó được nữa. Có thể họ cực kỳ muốn giải quyết vấn đề này, nhưng không thể, nên họ tìm kiếm giải pháp. Hoặc đó là một thứ mà bạn chưa từng nghĩ là bạn cần, nhưng giờ không sống thiếu nó được nữa. Và lần nữa, Jambox là một ví dụ tuyệt vời cho điều đó. Chúng đã nói với vài người về việc làm sản phẩm đó, và thật thú vị bởi vì...

Một câu chuyện nhỏ là khi chúng tôi khởi động Jambox vào mùa thu 2010, thị trường cho loa không dây so với thị trường loa nói chung là 0%. Đúng! 0%. Vào Giáng Sinh vừa rồi, tức là 2013, nó chiếm 78% thị trường. Vậy chỉ trong vài năm, chúng tôi đã thay đổi cả một ngành đã tồn tại từ những năm 50s-60s, và dẫn đầu nó. Và nếu tôi đi ra ngoài gặp một đống người và hỏi họ: Ai muốn mua một cái loa 199 đô dùng với điện thoại?

Tôi bảo đảm với bạn rằng sẽ có 0% số người bảo rằng "Tôi muốn sản phẩm đó", hay "Tôi muốn và sẵn sàng trả tiền." Nhưng chúng tôi đã thực hiện, và thay đổi cả ngành. Nên đây là lý do "Tại sao" là câu hỏi cực kỳ quan trọng, nó giúp bạn chỉ tập trung vào những gì bạn đang làm. Và tôi sẽ nói về một ví dụ trong lĩnh vực âm thanh, và Jambox là một ví dụ điển hình.

Sau đó tôi sẽ nói một chút về cách chúng tôi làm với UP, đặc biệt là máy UP24. Nó bắt đầu với thứ mà chúng tôi gọi là chiến lược trong ngành, và đây là một kiểu khung trải nghiệm, được chứ? Đối với chúng tôi, mọi trải nghiệm nội dung đang nằm ngay trên điện thoại của bạn. Đã qua thời của iPad, iPod và máy tính rồi.

Thế nên chúng ta cần một cách mới khác để tương tác, nó phải di động, thuận tiện, và chất lượng cao. Và đó là suy nghĩ nền tảng của chúng tôi. Tiếp theo, chúng tôi cho rằng trải nghiệm đó phải liền lạc xuyên không gian, thời gian, ở bất kỳ nơi nào, đi xe khác nhau, khi di chuyển, trong nhà hay ngoài nhà,... Về cơ bản đó là việc chúng tôi đang làm, và đó là lý do tại sao ngành này nên tồn tại.

Và đó là vấn đề con người. Rồi chúng tôi nói: Jawbone có vai trò gì? Tại sao chúng ta nên làm việc này? Và nếu bạn nghĩ về nó trong một bức tranh toàn cảnh hơn, về việc "kết nối vạn vật", với chúng tôi, loa trở thành thiết bị nhà thông minh. Và mọi người đang nói về đủ thứ mới trong nhà bạn, từ đèn tới cảm biến nhiệt độ, tủ lạnh, báo khói, hay bất kỳ thứ gì khác đều được kết nối thông minh, đó là thứ ai cũng muốn.

Nhờ đó mà chúng tôi đã bán được hàng triệu sản phẩm. Như đã nói, chiếc loa có thể là cổng kết nối cả thế giới đó cho bạn. Và nó có thể trở thành một cổng kết nối cho các phần mềm và dịch vụ trong nhà bạn. Đây là một chiến lược thú vị để giải quyết vấn đề của người dùng, nhưng tại sao nó lại quan trọng với Jawbone?

Cả hai điều này phải đi đôi với nhau. Vì [A] chúng tôi không phải là một công ty phi lợi nhuận, và [B], nếu bạn làm tốt, nó sẽ cho phép bạn liên tục làm ra những sản phẩm tuyệt vời, và nó cho phép bạn tiến về phía trước, làm những điều thú vị. Vậy đó là cách chúng tôi kết hợp nó lại. Sau đó chúng tôi xây dựng nó, cách chúng tôi nghĩ về trải nghiệm liền lạc này là: Hiện nay nó đang ở đâu, khi chúng ta bắt đầu làm loa Bluetooth?

Đó là công nghệ cốt lõi cho phép chúng ta kết nối mọi thứ. Chúng tôi nghĩ ngày mai nó sẽ đi đến đâu? Và rồi, sẽ thế nào nếu chúng ta có thể nhìn thấy tương lai? Thế là chúng tôi cố gắng sống trong tương lai, và nghĩ về những gì chúng tôi đang xây dựng như một bệ phóng để tập hợp người dùng lại một chỗ và cùng nhau tiến về hướng đó.

Và điều đó cũng cho chúng tôi thấy tầm nhìn về cách ra quyết định đánh đổi? Vì chưa thể đưa công nghệ này vào sản phẩm này được, nên phải chờ đến thế hệ sau, để người dùng đồng hành khi họ đã sẵn sàng tham gia. Và có rất nhiều cách để làm sản phẩm, và định nghĩa trải nghiệm không gián đoạn. Và chúng tôi nói rất nhiều về điều này.

Chúng tôi xác định bản thân là công ty về phần cứng, hay về phần mềm, hay về dữ liệu, hay về gì hết. Chúng tôi xác định bản thân là công ty về trải nghiệm. Đó không phải là về thiết bị vật lý hay về chức năng, mà là về hệ thống, về toàn bộ các mảnh ghép hợp lại với nhau. Và chúng tôi xác định "tại sao", nó trở thành tuyên bố về vấn đề.

Và chúng tôi nói: "Làm sao dùng phần cứng, làm sao dùng dịch vụ đám mây, làm sao dùng một phần mềm, một âm thanh, một nút bấm để giải quyết vấn đề trải nghiệm của người dùng? Và phải phân bổ hệ thống như thế nào cho đúng để xử lý vấn đề đó? Chúng tôi cần đột phá ở đâu? Làm sao kết hợp tất cả với nhau?

Vậy đó là một phần rất lớn trong tư duy. Nó giúp chúng tôi thành công, được chứ? Và khi chúng tôi nghĩ về những trải nghiệm này, chúng tôi cho rằng vấn đề nằm ở bối cảnh tại sao nó lại kỳ diệu đối với ngươi dùng? Và tôi nói hệ thống này phải là đầu bảng, và nó phải đạt tới kết nối ở cấp độ cảm xúc, mà khi thiếu nó, bạn sẽ thấy trống vắng.

Kiểu như tôi phải trở về nhà để lấy nó, nếu lỡ quên mang theo. Đây là những nguyên tắc áp dụng cho tất cả. Và chúng tôi luôn tự hỏi liệu sản phẩm này đã đủ chưa. Chúng tôi kết hợp tất cả lại thành một khung trải nghiệm. Nó trở thành bản mô tả cho đội kỹ thuật và đội thiết kế, và tất cả mọi người làm việc trong công ty.

Để họ nhìn lại và hỏi: Chúng ta đang làm gì? Và tại sao? Nó hoạt động thế nào? Và làm sao tạo ra thứ hơn thế nữa? Rồi chúng tôi tạo ra một quy trình lớn, Blueberry ở đây là tên mã nội bộ. Nhưng quy trình trải nghiệm người dùng sẽ có tài nguyên tốt hơn, nhờ lắng nghe người dùng, theo một cách rất cụ thể, để tìm kiếm những thông tin chủ chốt, rồi lên ý tưởng, rồi bắt đầu phát triển.

Ở phần "Tại sao", chúng tôi liệt kê các vấn đề của người dùng. Những nguyên tắc để tiếp cận vấn đề là gì? Giải pháp là gì? Rồi sản phẩm đòi hỏi những gì để có thể hiện thực hóa. Gì vậy Sam? >> Anh nói về cách anh cân bằng giữa việc người dùng không bao giờ nói rằng họ muốn mua một cái loa 200 đô, và quy trình nghiên cứu người dùng không?

Vâng. Đó là 2 việc khác nhau. Có rất nhiều lớp trong việc nghiên cứu người dùng. Nên chúng tôi xem xét... Đó là câu hỏi rất hay. Có lẽ các bạn chưa quen với việc này, nhưng có rất nhiều công cụ chuẩn mực để khảo sát nhóm, như kiểu hỏi: Bạn có muốn thử cái này không, muốn mua cái kia không, muốn tính năng nọ không?

hay tôi có quan tâm cái này không? Đó là một cách làm. Và cách đó thường không giúp ta tìm được câu trả lời hay. Chúng tôi hỏi theo kiểu khác. Như là: Bạn nghe nhạc cùng với người khác nhiều đến mức nào? Bạn phát nhạc bằng cách nào? Bạn có dùng tai nghe không, hay bạn nghe bằng loa trên điện thoại? Bạn có thường nghe với người khác, hay nghe một mình?

Bạn có thường chia sẻ?... Chúng tôi sẽ hỏi rất nhiều. Chỉ là hỏi khác đi thôi. Chúng tôi không hỏi cụ thể bạn muốn cái này cái nọ không. Chúng tôi hỏi hành vi của họ là gì? Họ sống như thế nào? Và bạn bảo họ: Này, nếu tôi có một thứ có thể giúp bạn... Ví dụ điển hình là iPod. Nếu bạn hỏi một người rằng họ có muốn mang cả ngàn bài hát đi khắp nơi không?

Nghe quá tuyệt. Không phải là: Bạn có muốn một chiếc máy nghe nhạc kỹ thuật số không? Và nhớ là với giá đắt hơn một cái điện thoại? Nên bạn phải tách bạch về những câu mà bạn có thể hỏi để có thể giúp bạn tự đưa ra những đánh giá tốt hơn, thay vì khiến người khách đưa ra đánh giá cho bạn. Và tôi nghĩ việc đó phải thật tách bạch.

Chẳng có ai có thể bảo bạn nên làm gì, nếu được thì họ đã làm rồi. Nên bạn mới chính là người ra quyết định. Bạn đưa ra giả thuyết, bạn có ý tưởng sáng tạo, bạn tạo ra đột phá. Bạn phải dùng những người này để giúp bạn làm tốt hơn nữa. Đó là sự khác biệt. Được chứ? Rồi. Giờ tôi sẽ nói một chút về UP24, đây là sản phẩm đã tung ra thị trường, thiết bị không dây để theo dõi sức khỏe.

Và "tại sao" của UP24 thực ra rất đơn giản. Trước hết, tôi sẽ nói về "tại sao" của UP. Ý tưởng chính là chúng ta biết rất nhiều thứ về thế giới hiện nay, qua Twitter, Facebook, mạng xã hội, internet, Google,... nhưng lại chẳng biết gì về bản thân chúng ta. Chúng ta chẳng biết tại sao có ngày ngủ đủ 8 giờ nhưng thấy mệt mỏi, có khi 3 tiếng lại thấy tuyệt vời.

Chẳng hiểu tại sao, phải không? Nên chúng tôi nghĩ: Liệu có thể dùng công nghệ cảm biến để giúp mọi người hiểu hơn về bản thân họ không và giúp họ đưa ra những quyết định để sống tốt hơn? Và sản phẩm đầu tiên ra đời. Đến sản phẩm thứ hai, chúng tôi bảo: Tuyệt! Giờ chúng ta đã có kết nối không dây, không chỉ là về Bluetooth hay wifi, mà là tôi có thể dùng những thông tin thời gian thực để hiểu chuyện gì đang diễn ra với tôi, và có hành động thỏa đáng.

Tôi có thể dùng dữ liệu theo cách có liên quan và có ý nghĩa hơn vào những thời điểm quan trọng. Tôi có thể xem lại các chỉ dẫn một cách có hệ thống để giúp tôi làm nhiều thứ hơn. Và tôi muốn được truyền động lực, bởi vì mọi người, bạn biết đó, họ biết rằng họ muốn tốt hơn, nhưng họ không làm được và bỏ cuộc.

Và họ muốn tương tác dễ dàng hơn. Vậy đây là những điều giúp chúng tôi phát triển UP24. Chúng tôi có 5 điều cốt lõi này, đây cũng là những lý do "tại sao" chúng tôi xây dựng sản phẩm. Và quan điểm của chúng tôi chính là chúng tôi có những chỉ dẫn cơ bản đối với khung trải nghiệm, trong đó nói rằng mọi thứ mà chúng tôi làm với UP là giúp mọi người theo dõi và thấu hiểu, họ tự theo dõi và tự hiểu, nghĩa là biến mọi dữ liệu thành tri thức.

Và thứ ba là hành động. Theo dõi; Thấu hiểu; và Hành động. Đây là những chỉ dẫn cơ bản cho mọi thứ chúng tôi làm về thiết bị theo dõi sức khỏe, và cũng cho tổng thể mọi thứ mà chúng tôi làm. Nghĩa là giúp mọi người hiểu kết quả nhiều hơn nữa. Dữ liệu là tốt, thấu hiểu còn tốt hơn. Hãy biến nó thành những thứ mà họ có thể tạo ra sự thấu hiểu và từ đó đưa ra hành động.

Nên những việc chúng tôi có thể làm với thiết bị để lấy nhiều thông tin hơn, giúp họ tương tác, và tìm những cách thức để hướng dẫn hành vi, đều thực sự rất thú vị. Và đó sẽ là khung làm việc cho cả hệ thống. Sau đó bạn có thể nghĩ về thiết kế đó, làm sao xây dựng hạ tầng dữ liệu, hệ thống thông tin, cách xử lý nó, làm sao làm đưa nó lên thành trải nghiệm ứng dụng?

Và đây là sự kết hợp giữa theo dõi, thấu hiểu, và hành động. Về cơ bản thì phần theo dõi thiên về mảng phần cứng hơn. Kiểu như làm sao thiết kế bộ pin? Làm sao thiết kế hệ thống nhúng và các vật liệu? Làm sao bạn đeo nó? Có dễ dàng không? Để bạn có thể tạo thói quen mang nó trên cơ thể, đúng không? Rồi bạn lấy những dữ liệu đó, rồi minh họa những thông tin đó.

Kiểu như nếu tôi bảo nhịp tim báo là 75, vậy là tốt hay xấu? Ai biết đáp án nào? Tôi không biết. Vì còn tùy. Tùy vào bạn làm gì, bạn là ai, chuyện gì đang diễn ra? Chỉ có dữ liệu thôi chưa đủ. Bạn phải đặt nó vào bối cảnh, tại sao nó quan trọng, biến nó thành hành động. Và đó là phần thứ ba. Hành động là mấu chốt.

Nó phải giúp tôi hiểu dữ liệu. Giúp tôi hiểu rằng nếu tôi tập thể dục lúc 4 giờ, tôi sẽ được thêm 4 giờ ngủ sâu vào buổi tối. Điều đó thật tuyệt, nên tôi sẽ đặt lịch đi tập thể dịch lúc 4 giờ, hoặc tương tự. Đó là điều chúng tôi đang làm. Cần rất nhiều hạ tầng để tạo ra trải nghiệm đó. Nhưng đó là cách chúng tôi làm phần mềm và phần cứng.

Đó là cách chúng tôi làm cả hệ thống. Và chúng tôi thường nói về những loại người dùng khác nhau, và họ quan tâm điều gì, và nhóm người dùng này hình thành từ điều gì? Ai muốn giảm cân? Ai muốn được xã hội ghi nhận? Ai đang phải chịu đau đớn? Ai chỉ muốn trông đẹp hơn? Và tại sao lại như vậy? Vậy, có rất nhiều điều khác nhau.

Và có những người vì lý do y tế nên phải dùng sản phẩm của chúng tôi. Và chúng tôi thiết kế một kiểu trải nghiệm khác. Chúng tôi nghĩ về việc sử dụng những nền tảng như điện thoại và cách đẩy thông báo như một phần của hệ thống. Chúng tôi coi thông báo là một công cụ để thay đổi hành vi. Và chúng tôi bắt đầu lập bản đồ những thứ này.

Hành động thông minh là gì? Làm sao để nó phản hồi thời gian thực, dễ tùy biến, thể hiện tiến độ, thật sự hữu ích, và cá nhân hóa cho tôi? Rồi với từng nhóm người dùng cụ thể, chúng tôi vẽ một câu chuyện, và câu chuyện này sẽ chuyển sang các nhóm thiết kế và kỹ thuật. Chúng tôi làm cùng nhau, và họ bắt đầu phát triển tất cả.

Nó tạo ra cho chúng tôi một bộ những giới hạn. Với tôi thì giới hạn là tốt, vì chúng là những cơ hội để tiến bộ, để hoàn thiện, để đơn giản hóa và để thúc đẩy bạn đi tìm đáp án đúng để giải quyết vấn đề theo cách đơn giản nhất. Thế nên chúng tôi tạo ra rất nhiều giới hạn cho những việc đang làm. Đây là một kiểu kể chuyện để giúp một người đạt mục tiêu, cách họ thực hiện, và những gì chúng tôi dùng theo thời gian thực.

Nên... Rồi chúng tôi đưa ra một lớp trải nghiệm cấp hai. Nếu làm được cái này, chúng tôi sẽ đưa nó vào. Nếu không quá rối rắm, chúng tôi sẽ đưa vào. Vậy đó là tổng quan về cách chúng tôi thực hiện và còn vài phút nên tôi sẽ trả lời bất kỳ câu hỏi nào. >> Vâng, tới phần hỏi đáp. >> Vâng. >> Anh có khoảng 15 phút.

Tuyệt. >> Giả sử thầy đã có sản phẩm tốt, mọi tính năng đều được làm đúng hết, tất cả mọi thứ, đủ để thỏa mãn, và tiếp theo là quy trình thiết kế. Làm sao thầy tiếp cận tổng thể vấn đề này? Làm sao chia nhỏ nó ra, vì mọi việc đều quan trọng? Để vẹn cả mọi đường, đó là vấn đề mà thầy biết đó...

Nhưng mỗi tính năng lại đều không tách biệt với nhau. Làm sao để dự án được thống nhất, đại loại như vậy? >> Phiền anh lặp lại câu hỏi để tiện quay phim hơn. >> Vâng. Tôi nghĩ câu hỏi này là khi bạn có một số tính năng khác nhau mà bạn cố gắng xây dựng, làm sao xem xét nó ở cấp độ hệ thống để hiểu rằng chúng ta không chỉ đánh đổi trong một nhánh nhỏ, mà phải đánh đổi trên toàn bộ hệ thống?

Tôi nghĩ đó là câu trả lời cho bạn. Bạn làm đúng vậy luôn: Đừng xem xét nó như một nhánh nhỏ. Bạn phải nỗ lực rất nhiều. Vì khi nhóm còn nhỏ thì rất dễ. Vì các bạn đều ngồi quanh bàn, các bạn nhìn nhau, và ra quyết định theo thời gian thực. Khi công ty ngày càng lớn, bạn phải nỗ lực hơn trong giao tiếp khi mọi người họp, và có người nói: "Này, nếu anh làm thế, nếu anh thực hiện theo cách đó, thì tôi không thể đảm bảo chất lượng như anh muốn được."

Rồi người nọ nói: "Này, nếu anh làm vậy, rất khó để tôi xoay trở, tôi không thể chạy hết các thuật toán để tối ưu hiệu suất pin như anh muốn được." Khi bạn bắt đầu xem xét tổng thể hệ thống, bạn sẽ bắt đầu thấy mọi người nói lên nỗi khó khăn của họ là gì. Và họ không hiểu, rằng nếu đánh đổi như thế thì sẽ tác động tới tôi.

Nên bạn phải gom họ vào một phòng và nói hết ra. Chúng tôi ghi hết những thứ chúng tôi lên tường và lên mọi nơi, và xem việc đánh đổi đó tác động như thế nào đối với toàn bộ tất cả những nhánh nhỏ này. Vì ai cũng biết việc đánh đổi của họ sẽ giúp họ có được điều gì, nhưng không biết nó tác động cả hệ thống như thế nào.

Chúng tôi vừa trải qua việc đó với UP3, một sản phẩm mà chúng tôi mới giao hàng vài tuần trước, nó định nghĩa làn sóng tiếp theo của các sản phẩm đeo được trong mảng theo dõi sức khỏe. Chúng tôi phát minh ra một hệ thống cảm biến hoàn toàn mới. Khoa học thô đã được phát triển và chúng tôi phải sản xuất rất nhanh, thậm chí những đánh đổi như thay đổi vật liệu điện từ, nó tác động thế nào đến tính ổn định, nguồn hàng, khả năng truyền tín hiệu,...

Và họ không nói chuyện riêng, mà phải cùng họp. Chúng tôi gọi điện 3 giờ mỗi ngày, và họ xem xét mọi thứ với nhau. Tuy chán nhưng chúng tôi phải làm, phân tích nó ra thật chi tiết. Khi còn nhỏ thì rất dễ vì chỉ cần nhìn vào đó thôi. Nhưng bạn luôn phải đưa ra định nghĩa về việc bạn đang làm trên cả hệ thống, cho nên phần lớn sẽ thuộc về cấp độ cao hơn.

Chúng tôi giải quyết vấn đề gì? Tương lai nó sẽ thế nào? Làm sao thứ này khẳng định điều đó? Xin mời. >> Nếu một start-up muốn xây dựng một hệ thống về sau, thì nên tập trung vào một thứ nhỏ trước hay là nên bắt đầu xem xét cả hệ thống và cách kết hợp tất cả với nhau? >> Tôi nghĩ hệ thống là một kiểu phương pháp tư duy.

Không phải là một hệ thống vật lý, kiểu đơn giản hay phức tạp. Kiểu như máy bay là một hệ thống phức tạp, xe hơi là một hệ thống phức tạp. Có khi khiến một cái điện thoại đơn giản hơn cũng là hệ thống phức tạp. Một ứng dụng cũng nên xem là một hệ thống. Làm sao tất cả kết hợp với nhau? Bộ nhớ, niềm vui và trải nghiệm, việc bạn đang làm, sự kết nối,...

đều là hệ thống. Ý chúng tôi thiên về kiểu hệ thống như vậy hơn. Với chúng tôi, nó là phần mềm, phần cứng, và dữ liệu nhưng trong bất kỳ thứ gì cũng đều sẽ có một kiểu hệ thống. Nên nó thiên về việc nghĩ về những đánh đổi có thể tác động lên toàn bộ các phần khác trong hệ thống. Bạn hiểu ý chứ? Xin mời.

Quy trình ra quyết định là gì, khi tạo ra những sản phẩm không liên quan với nhau? Như thiết bị theo dõi sức khỏe, rồi lại làm loa như kiểu Jambox, nhiều phiên bản Jambox. Vậy quy trình đó là gì? >> Chúng tôi vẫn có một thuyết thống nhất, về thời điểm nào đó kết hợp tất cả những trải nghiệm này với nhau, và điều gì sẽ diễn ra khi nó chạm tới thời điểm mà chúng tôi tạo ra cho bạn một cỗ máy đọc bối cảnh, mà khi đeo thiết bị trên người, nó sẽ khiến mọi thứ xung quanh bạn thông minh hơn.

Như nếu tôi biết cảm xúc của người dùng, tôi có thể bảo Spotify bật bài nhạc phù hợp với tâm trạng trên Jambox, tôi có thể bảo TV rằng bạn không thích quảng cáo và tua nhanh qua tập sau. Hoặc có thể khuyên bạn không nên xem "Trò chơi Vương quyền" vào tối chủ nhật vì bạn sẽ khó ngủ. Và bạn bắt đầu thấy... Tôi nghiêm túc đấy.

Và những mảnh ghép bắt đầu kết nối với nhau. Chúng tôi nghĩ tới cấp độ đó, và bắt đầu làm từng thứ để có thể đến được điểm đó. Làm sao tạo ra sự ổn định? Làm sao tạo ra hệ thống phân phối? Làm sao quy mô hóa sản xuất? Làm sao kết hợp tất cả lại với nhau? Vậy đó là tầm nhìn thống nhất của chúng tôi.

Chúng tôi xem xét nhiều ngành với những động lực khác nhau, phát triển với tốc độ khác nhau, có những vòng lặp thay đổi khác nhau. Ví dụ như những gì đang diễn ra với iPad và iPhone. Chúng ta đều quen với việc đổi điện thoại mới mỗi năm. iPad lại không theo cùng nhịp độ như thế. Vòng lặp thay đổi khác nhau. Trường hợp sử dụng khác nhau.

Vấn đề nó giải quyết cũng khác nhau. Nên chúng ta phải thích ứng. Bạn không thể đổi nhà mỗi năm. Vòng lặp đó khoảng 15 năm. Nên cách họ phát triển trong bối cảnh thế giới như vậy, họ phải suy nghĩ như vậy. Bạn phải xem xét về lĩnh vực của bạn, vòng lặp thay đổi, trường hợp sử dụng, cách tất cả kết hợp với nhau, và các động lực đều rất khác nhau.

Xin mời. >>Trước hết, bức tranh toàn cảnh của Jawbone là gì? Ý em là khi người dùng mua, tại sao họ trả tiền? Vì thiết kế đẹp, hay ý tưởng hay, hay vì có chức năng nào đó quan trọng? >> Bạn đang nói về phần nào? Có phải về phần lưới? >> Vâng, phần lưới bề mặt. >> Vâng, phần lớn đều được thiết kế bởi Eve và đội thiết kế.

Và kiểu như họ tạo ra một bề ngoài hoàn toàn mới. Bạn nhìn biểu tượng là biết ngay chức năng gì, tại sao nó ở đây, vân vân... Đó là một phần sứ mệnh của chúng tôi. Chúng tôi muốn chuyển tải cảm xúc về chất lượng. Có người thích, có người không. Đó là bản chất của thiết kế. Nhưng đều thuộc về cùng một quy trình. Xin mời.

Sao thế? >> Không có gì. >> Vâng, câu hỏi này hơi khác với những câu khác. Nhưng khi làm một sản phẩm cụ thể, làm sao thầy xử lý những thay đổi không cần thiết, và làm sao thầy sử dụng những thông tin mà thầy thu thập được? Như khung làm việc và quy trình hoạt động như thế nào? >> Câu hỏi rất hay. Tôi sẽ quay lại nói thêm chỗ đó.

Câu hỏi là: Đó không phải là sản phẩm đầu tiên, mà khi bạn đã ra mắt sản phẩm đầu tiên rồi, thì suy nghĩ của bạn sẽ thế nào, và nó tác động tới quy trình ra sao? Tôi sẽ mở lại slide lúc nãy cho thấy kiểu chúng tôi thực hiện, và về quy trình. Nó đây. Vậy... Xin lỗi vì phải tìm lại hơi lâu. Vậy, đó là một câu hỏi hay.

Vậy đây là cách bạn tạo ra một thứ hoàn toàn mới từ số không. Bạn bắt đầu ở đây, làm theo thứ tự, rồi bạn đến được đây. Và bạn học được rất nhiều. Hồi làm bản UP đầu tiên năm 2011, nó không chạy được. Thế là chúng tôi phải làm lại toàn bộ. Và điều chúng tôi đã làm ở đây là thực sự nói với họ cả đống thứ mà họ nên suy nghĩ cân nhắc lại và mở ra một đống vấn đề mà chúng tôi phải giải quyết.

Và họ đã bắt đầu thực hiện với một tốc độ khác, vì đôi khi phải mất nhiều năm mới kết quả. Ước mơ thì nhanh hơn nhiều so với thực hiện, phải không? Rồi những công nghệ cốt lõi như cảm biến, pin, chip xử lý, việc xử lý, quản lý bộ nhớ, và đủ thứ như vậy... Và bạn biết gì không? Đây là những vấn đề chúng tôi phải đối mặt.

Sẽ thế nào nếu chúng tôi có thể xử lý song song? Thế là chúng tôi bắt đầu làm ở đây. Họ xem xét nó trong nhiều phần khác nhau trong quy trình. Vẫn còn chỗ để tạo đột phá, nhưng chúng tôi thấy điều gì đó ở đây, và nói: Hãy đi thẳng vào phần lên kế hoạch và phát triển, không cần phải làm lại hết. Vậy chúng tôi có sự linh hoạt nếu không cần phải làm những thứ đó.

Chúng tôi biết rằng đối với chúng tôi thì không khó để tìm giải pháp từ có dây sang không dây. Chúng tôi không lo lắng về chuyện phải đánh giá quá nhiều ý tưởng. Chúng tôi có thể bỏ qua vài bước, nếu bạn biết cách ra quyết định. Đối với chúng tôi thì nó thiên hơn về việc lấy tinh thần đột phá và sự sáng tạo rồi thực sự tạo ra một thứ gì đó theo cách thật tập trung.

Và đó là những suy nghĩ của chúng tôi. Chúng tôi có khả năng nhảy tới lui hoặc bỏ qua những bước không cần thiết. Xin mời. >> Em tò mò độ lớn của công ty về mặt số lượng nhân viên, và khi thầy tuyển thêm nhiều nhân viên, thầy sẽ gặp phải những vấn đề gì, vì đó không chỉ là 5 người, mà rất nhiều người cùng làm một dự án, và rồi cả vấn đề công cụ để tổ chức và làm việc với nhau nữa?

Vâng. Câu hỏi rất hay. Vậy câu hỏi là chúng tôi lớn cỡ nào? Và khi chúng tôi phát triển từ nhóm nhỏ thành lớn, nó đã thay đổi quy trình tư duy, các công cụ, và cách chúng tôi làm việc với nhau như thế nào? Chúng tôi có khoảng 500 người, và các trụ sở rất xa nhau. Một văn phòng ở Sunnyvale, trụ sở chính ở San Fransisco, văn phòng ở Seattle, Thượng Hải, Pittsburgh, Luân Đôn.

Và chúng tôi có nhiều đội phân tán với những vùng giao tiếp rất thú vị. Nhưng nó cũng giúp tìm kiếm nhân tài, và những người thú vị ở những khu vực nhất định. Tôi muốn nói tới điều lớn nhất mà chúng tôi luôn cố làm tốt hơn, đó là việc giao tiếp giữa tất cả những người khác nhau, làm việc theo cách khác nhau, và bắt buộc họ phải ngồi vào bàn và nói: "Tôi đang làm việc này, tôi phải đánh đổi những gì?

Tôi nghĩ cái này có thể ảnh hưởng tới anh." Rồi lắng nghe người khác và thấu hiểu họ. Và luôn nhớ rằng chúng ta đang xây dựng hệ thống, và đây là kết quả khi kết hợp tất cả lại với nhau. Và chúng ta giải quyết vấn đề thế nào? Nhưng phần lớn là thúc đẩy sự giao tiếp. Và làm những việc như tôi dùng UP3, gọi điện mỗi ngày, tốn 2 tiếng rưỡi mỗi ngày với toàn đội, từ vật liệu, nguồn hàng, sản xuất, thiết kế cảm biến, firmware, cơ khí, tất cả...

Và họ đều lắng nghe cập nhật của người khác để hiểu những đánh đổi đó là gì, và tôi luôn thúc đẩy sự giao tiếp đó. Xin mời. >> Vào lúc nào thì thầy quyết định mở rộng? Và làm sao thầy quyết định mở rộng phần nào trước? >> Câu hỏi rất hay. Câu hỏi là: Làm sao chúng tôi quyết định mở rộng, và khi nào? Về mặt địa lý?

Hay đội ngũ? Hay là thị trường? >> Vâng, làm sao thầy kết nối những điều đó lại với nhau? >> Tôi nghĩ phần lớn đều phải cân nhắc kỹ lưỡng. Kiểu như chúng tôi xây dựng rất nhiều thứ ở Trung Quốc, nên chúng tôi phải có đại diện ở đó để quản lý. Đến thời điểm đủ lớn thì chúng tôi muốn lập cả đội ở đó. À, chúng tôi đã mở rộng bán hàng.

Tôi nghĩ chúng tôi đã có trên 56 quốc gia, hơn 100.000 điểm bán hàng. Bắt đầu từ Bắc Mỹ, mở sang Châu Âu, rồi tới Châu Á. Bây giờ chúng tôi nghĩ hơi khác về thời điểm bắt đầu và địa điểm mở rộng. Vậy có rất nhiều yếu tố cân nhắc, và cần thời gian. Lần nữa, một phần chính là: Chúng tôi muốn tới đây, muốn phát triển tới đây, muốn thích ứng kinh doanh kiểu này,...

và còn phải tùy cơ hội nữa, đúng không? Có những thị trường mà chúng tôi gia nhập vì có những đối tác tuyệt vời, chúng tôi có những đề xuất rất tốt, văn hóa cũng thích hợp với việc chúng tôi đang làm. Với máy UP, Trung Quốc là một thị trường khổng lồ. Chúng tôi lên kệ ở cửa hàng Apple, và đó là chứng nhận tuyệt vời, và chúng tôi cưỡi con sóng đó.

Và lần nữa, chúng tôi biết là phải làm ở Trung Quốc, đó là một cột mốc của chúng tôi. Nên tôi nghĩ việc đó tùy vào bạn đang làm gì, và tình thế lúc đó có phù hợp hay không. Xin mời. >> Tại sao thầy chưa làm tai nghe? >> Với chúng tôi, với từng mảng, chúng tôi được hỏi về nhiều thứ, tai nghe là một ví dụ.

Trước hết, khi bước vào một lĩnh vực, chúng tôi muốn thay đổi nó, và bảo đảm rằng có thể tạo ra sản phẩm tốt hơn những thứ hiện có. Và phải làm tốt hơn ở một hoặc hai bậc, hoặc kiểu như vậy. Và đôi khi thị trường chưa sẵn sàng. Đôi khi công nghệ chưa sẵn sàng. Đôi khi, chúng tôi chưa sẵn sàng. Chúng tôi chưa đủ sức để đồng bộ và kết hợp tất cả lại với nhau.

Nên điều quan trọng là khả năng kết hợp, bất kể là sản phẩm hay lĩnh vực nào. >> Rồi, một câu hỏi nữa. >> Xin mời, áo len đỏ. >> Chào! Với một công ty phần cứng, vòng đời sản phẩm luôn là vấn đề đau đầu. Sam có nói về những người khóa trước có điều hành công ty phần cứng và công ty phần mềm, và không biết thầy có thể chia sẻ gì đó thêm không?

Có phải thầy đang điều hành JawBone như một công ty phần mềm để lấy ý kiến người dùng trong suốt toàn bộ quy trình? >> Tôi nghĩ câu hỏi là: Công ty phần cứng rất khó điều hành, chúng rất khác với công ty phần mềm. Làm sao chúng tôi điều hành JawBone, phải không? Tôi nghĩ rằng không có hình mẫu nào trong việc chúng tôi làm cả.

Trước đây chưa từng có, nên chúng tôi đang ở đầu của mũi tên. Chúng tôi kết hợp những lĩnh vực chưa từng làm việc cùng nhau để tạo ra trải nghiệm. Đôi khi rất khó khăn. Nhưng rất vui. Chúng tôi cố dùng phần tốt nhất trong mọi thứ, dùng những phương pháp tốt nhất để đẩy nhanh vòng lặp cải tiến phần mềm, thử nghiệm, phát triển, và ứng dụng nó, áp dụng cho phần cứng.

Rồi lấy sự dứt khoát cần thiết trong mảng phần cứng và áp dụng cho thiết kế phần mềm, bởi vì phần mềm nền web và phần mềm di động rất khác nhau. Hóa ra là xây phần mềm di động thực ra khá giống với xây phần cứng, khi bạn thực sự chỉ có một cơ hội và bạn phải làm đúng ngay từ đầu. Chúng tôi cố học mỗi chỗ một ít, để giúp chúng tôi trở nên tốt hơn.

Và đó là việc của tôi, và việc của những người lãnh đạo cấp cao khác là tìm kiếm cơ hội để lấy ra những điều tốt nhất trong mọi thứ và kết hợp chúng lại. Tôi không nghĩ là trước đây có công ty nào giỏi đều cả hai mảng phần cứng và phần mềm. Và đó là điều chúng tôi đang nhắm tới. >> Cảm ơn anh rất nhiều.

Rồi. Cảm ơn các bạn!

Lecture 17 - How to Design Hardware Products (Hosain Rahman)

Very exciting, and thank you, Sam for having me. Sam and I have known each other for, for a long time because we were fellow Sequoia companies. And we met in the early days of when he was on his company journey and so it's cool. So what he asked me to talk about today, was a little bit about sort of the hardware journey of building products. So what I want to do is give you guys a little bit of an overview of Jawbone.

What we do how we think about the world, and that informs how we build products, and goes specifically into in the process of how we design, how we develop, and how that all kind of comes together. And sort of what we do to change categories. So, first off, I always like to start with, with sort of the broadest thinking and the way we look at the world.

As we think of ourselves at this intersection of really crafted innovation in engineering that's almost invisible to the user, in terms of it's functionality. And that's at the intersection of even beyond design. We've been doing design products for over a decade now. We think of it as going, the conversation has shifted even beyond design into beauty. And it's that intersection of engineering meets beauty, and the whole point is to help people with a better life with technology.

And largely speaking, we do play in this world of what everyone's talking about now is Internet of Things. We were there much longer before there was such a, a moniker. And the way we think about that is it's smart devices that have computing power and connectivity with sensors in them that are measuring all kinds of things. They're wirelessly connected and they're all talking to you, and we started on this journey really, really early, right, actually out of engineering school here.

And we were developing core technology, we decided to build consumer products around that. Our first consumer product was the headset. We sort of created a headset that become a wearable computer. It was the first Jawbone headset. That was when we started thinking about wearable computing. We then invented the wireless speaker space around Bluetooth audio and I'll talk a little bit about that journey. And then most recently, we focused our attention on through this whole wearable health revolution, and using a lot of the sensors that we did in the first generation of headsets and applying them to other parts of the body to understand more about users.

So our view of, of this world, having been here for a long time, is that it's a little bit of a mess in the internet of things. Everything in the world is smart and connected, and everything has an app built to it. That doesn't mean that it's easy for users, right? Your microwave, your refrigerator, your car, your XBox, your Xfinity, Comcast, everything has an app. It doesn't talk to each other.

It's really confusing for the user. So we think that there's a desperate need for an organizing principle around all of this. And this is sort of the core of when we start to think about how we build and opportunities to sort of create products, we think about where is the world going? So, if there is going to be such a world that everyone's talking about around The Internet Of Things which is happening, you do desperately need these organizing principles so that it's easier for users to understand how to come in and interact with these services.

So we think the thinking needs to shift from being less about the actual things to being about the individual user. And so ultimately, when everyone's talking about wearables and you have things like Google Glass and you have the stuff that we do and Apple Watch and all this stuff, ultimately what we believe is that when you have things on your body 24/7, they become this kind of perfect context engine for everything in the world around you, right?

So my phone is not on me, it's in my jacket or sometimes on the charger. But my Up is on me, and it understands everything that's happening with me. It's tracking my heart rate. It's tracking my respiration. It's tracking all these different things. And when I say context engine, I know I can tell the smart thermostat in my nest that I'm hot or cold. That device doesn't have that understanding.

I can tell it's hot, that device I'm hot because I'm sick, went for a run, it's hot outside. I can tell your car that you're falling asleep, that you're agitated or irritated. So this is ultimately where we think the world is moving, is that wearables are going to be the center of this revolution around everything being connected and smart and they're going to drive what a lot of those interactions are going to be and how they're going to work.

Right? And so, that's sort of the first principle that we think about when we start to think about okay, where are things going, and what we should, should we build, and, and how do we think about new categories, right? So in order for the vision of what we're talking about to happen, you actually need to be great at almost everything. We need to be great at what we call the full stack.

We have to be amazing at building hardware, and these are hardware experiences that people have to keep on all the time. Right, you have to wear them 24/7, because if you don't, then everything that I'm talking about is sort of a castle in the air, right. You can't actually create a service that people will engage with, or get lots of data off it to then go power all these other things, if it doesn't start with great hardware.

So that's where we start. We try to build, you know, these magical experiences in hardware that absolutely powered by software. We have developed world class software application expertise. We've gotta be as good there from an engagement perspective as something like an Instagram or Whatsapp. And then on the data side we've gotta know what to do with this, this massive amount of information, and process it and push it, and have it work for the user.

So we really see ourselves as being at the intersection, for the first time, of a company that's doing hardware, software, and data, as three kind of equal stools that have to work together in order to unlock that experience around somethings that's on you, knowing what's happening. And then talking to the rest of the world around you. So that's a pretty key piece of what we do. I think it's different than what a lot of other companies do.

And it allows us and requires us to play at all levels of stack. Now this was a complicated thing for us to put together. Because typically, you know, people who are great at hardware understand mechanical engineering, electrical engineering, how those things interact, wow you build at scale, how you build tools, etc. They're not typically great at building software and services, right. It's a very different discipline and a very different skill set.

So when we first put those pieces together, that created a lot of interesting friction in the company. Our software and application team was so used to moving really, really fast and iterating. Whereas in the hardware world, you gotta take your time because your iteration cycles are much more deliberate. You have tooling that takes 16 weeks. You can't just tweak stuff, and you can't hack it in the same way.

And so what was interesting to see is we put all these pieces together, the hardware team learning to move faster, the software guys thinking more about how do they resolve experiences before you actually have to ship it versus just throwing something out and AB testing it and then the data science sort of informs all of that with sort of more information to make different kinds of decisions.

So, how do we think about, how do we go, how do we build products, how do we change categories? First of all, everything for us is a system. Right, we don't think about it discreetly just as a piece of hardware, discreetly as an application or discretely as a platform. We think about it across the whole thing, and so this is an example with Up, right where we have these tracking sensors on the body, algorithms there.

It connects to the phone where you have this engaging application service experience. We use the sensors in the phone. That talks to a lot of stuff that we're doing in the cloud, where we're taking all that information, driving insight on it and then we have a huge platform of thousands of developers where they have thousands of apps that then plug in and also create more experiences. And so we think about it across the whole spectrum and I'll come back to this system think in a second.

So what is the actual process of, of creation look like? And this is fun for me cause we don't actually talk about this very often. It's quite you know sort of, we keep in confidential and private and I know that we are talking, now that we, we're on sort of a live cast everywhere. So it's fun for me to talk about this for the first time, because it's not or it's, it's quite a deliberate process, right.

And this is a little bit at what it looks like. And, this is kind of a map where we are very unbridled in our imagination in the exploration phase. We start to validate some of our concepts, bring those ideas tighter and tighter and tighter, and then we actually start to build a product, launch it and then iterate, right? That's the simplest way to look at. I'll take you through each of these steps.

So in the exploration phase, it is very wild. It's imaginative. We think about the vision of where the world's going, what our strategy is, what does the brand stand for. And we think of it a lot of, of what you guys do here. You're dreaming, you're imagining it, how do you disrupt, what's the future going to look like? It is a little bit science projecty sometimes, and we talk about it in that way, right, and we do build from inspiration and insight.

And that's, it's sort of raw creativity. And we want to create, and we try to create, a form where that's okay, because a lot of times in companies, that gets lost. And then, when we sort of bring it to early validation, where I always say, like, look, everyone, when you're doing this stuff, you have to now take those concepts and prove them a little bit like you do a PhD thesis, right?

Where you have your conclusions, you've done your, you know, empirical data collection, and you start to say hey look, here's where we see it going. Here's what it's going to do, right? And you outline the story. And then once we've sort of signed it off on that phase that we think okay, you know what, this theory's right. We start to go into a concepting phase where we start to really think about what is the experience and what's possible.

And this is a, this is another interesting opportunity for innovation at a more specific level of how this thing will come to life, or what it is, and how would we sell that experience, and how would we tell that story. And then it, and then we decide that it's a program. And it goes into a heavy planning phase, where we start to look at and say, okay.

We're doing this. We've gotta ship it. There is no turning back right? What are the trade-offs between all the creativity and all the ideas we want versus what does the physics dictate? What are the you know battery power or all the different constraints that we have and start making those trade-offs and start to look at, you know, how do we pull that together? And then we move into a development phase where it's a hand off between various stages.

And really various functional teams in the company and you pull it together and you're solving problems as you go implement this. And you launch it and you learn. And you see what users think. And then you start to think about where does this stand in that experience continuum that you've been imagining where the world's going to go. What have we achieved, what haven't? What have we learned from our users?

How does that change what we're thinking? And then we start right over again, right? So that's the broadest way to think about it. A little bit deeper on the exploration phase, right? So it is very much like a building and tinkering process, right. And, and a lot of it is driven by what we call demo Fridays, where people kind of have an opportunity to go showcase their work.

Because we find that that's a great way to pull it together, pull it in a form that others can consume it, and give feedback, right. And it's a, it's a, it's a really, it is a show and tell. Obviously hack-a-thons are a big part of it, there's lots of data that, that gets driven. And it's lead by our, our strategic developments, in which is traditionally called sort of an R&D team.

And there's participation from product and engineering both hardware and software but they're sort of taking a back seat and they're looking at what these explorations are, right? And, the executives in the company at this phase are more of a sounding board. They're there to poke and prod and tell people, hey think about this, or did you thought, did you try that, how does that work, right. So, in, in this phase, in order to move to the next threshold we think about it literally as, hey would I give this guy 50 grand?

It's a little bit like an angel investment, right? Would I give this guy 50 grand to go explore this and see if there's a there there, is there something to do. And our CTO is the, is the sort of final decision maker. He gets to sort of pick those things internally and say, you know what I, I like all the feedback. This is the one I want to go chase down and see what happens, right?

So then we get into this validation phase, and this is where it starts to get really interesting. Still led by R&D, but they're really poking at it and they're saying, how does this work? We have these leadership meetings with the broader cross-functional team. I have to show results. I have to go through a scientific process to outline, you know, why this works. Why, why is it going to happen.

And, and you'll hear. This is really when we start formulating a really important tool that we use in the company, which is what we call, why's. Defining the, why are we doing this? Why does this exist? What problem does it solve? I'm going to come back to that, in deeper in, in a minute, right? And so at this point, it's still an R&D lead. But this is when a lot of our industrial design team, you have Bahar, and, and a few project guys.

They come in, they start to think about, okay, how can I pull this concept into something physical that's hardware, and how is that going to interact with the rest of the pieces of the system? Our product experience team is still also driving a lot of the core values and, and what the storyboarding is. But it starts to become a lot more real, and this is when we start thinking about, okay, how would we build this?

You know, how expensive is going to be, what's the budget going to be, etc, right? And at that point, right, we start to really validate, can we actually build it? Or do we have to wait three years for batteries to be there or, or do we have to wait for this other innovation to happen, or do we have to wait from a budget perspective, or whatever it is.

Is there a business viability, and then we start to, really start to sketch kind of briefs. And this is where I come in, and make the final decision on, okay, I think this is the, there's really a there there. We can now take this to the next level and get it into, into a play. And then we go into the concept phase, right? And this is now when the, the responsibility shifts from the R&D folks to what we call product experience team.

And the way we think about product experience in Jawbone is sort of what everyone thinks of this sort of conventional design. So from industrial design to, you know, software design to audio design to, you know, anything in that touches that experience. We have writers on that team, story tellers, we have idea-people like Eve who are genius creatives. We have amazing, app level designers, graphic designers, everything. It's all in one team, and we call that product experience.

And their job is sort of from bits to atoms and back and all the way through to unify as, as one organization. And that's when they sort of take a hold of this, and they start to really kind of work out what is, and this is what we call, when you're starting to really drive the why's, right? Thinking about what's possible, there's a lot of innovation and creativity now in the actual implementation of how we're going to build and create a product.

And we start to say like, what are the most important things in that product? What are the most important problems we're going to solve? We call them hero experiences, right? What are we going to to do. What is the bar that, that will be acceptable, etc, right. And at this point we start to really resolve what we call these why's, which I'll show you again in a minute.

And why is that different from what anyone else has done. From the competition from the category. And then what is, where does it go, right. It's we don't like to do just one off things, we have to see a broader vision. And this is part of that, that creation experience, is we look at, at where do we think the world is moving, and how is this thing going to be a stepping-stone to that ultimate end vision.

And that's where the road map starts to get fleshed out, get, I have the ability here to come in and sort of be the final decision maker with my team and say, yep, we're going to move this to this next phase. And here is also where we look at some of these things. And when I get into some of the specific examples we have fast track programs, right.

So we took, for example, the Jambox when we were in this phase and we we said, we're not going to go through that phase, we're going to go straight into the development process, right. Because we want to get this thing out, we want to test it and market it, and move really quickly. So we have the ability to sort of circumvent our own process now and say like, okay let's go, let's go really rapid and fast track it, and recalibrate, kind of, the go to market possibilities, right?

So this is when we, after this stage now, it shifts from that product experience team to our product managers, who are really defining the business plan. When's it going to launch? When's it going to get into the retail calendar? When do, what is the, you know, software release cycle. Really prototyping actually starting to feel it and you're starting to make as I call a lot of those trade offs.

Where like, okay we wanted to build this, we can't do that, but here's what we can do. We want to be this way we have to, you know, we want these functional experiences, but we're going to sacrifice battery life. Whatever it is, that's where we start to really kind of pool those decisions and start looking at it. And, and it's really a big juggling act frankly at that, at that point right.

And so the, the product guys are, are driving that. And that's when again you know we, we sort of look at and synthesize all of what we've put together and we say okay, does it actually cross enough things off our list. Does it meet that, that minimum viability, right? Because we alway start with a very, as you can tell, like this very big wish list of what's possible and what we can do.

And then we start to whittle it down and say, is this cross enough of the value threshold that we think that it's, it's worth pursuing. And now can we actually move it into the development phase where again product management continues to lead it, but now you're starting to really get deep. And this is where engineering comes in and is really starting to sign off on like we can build it, here's a time schedule and how we ship.

And then again, you know, product team is looking at how should we go deeper on this, how can we increase engagement with a little innovations. Or the tuning, what are all the things that we need to do to sort of make that? You know one of the things that we've been fortunate to have is a lot of wonderful response to the products that we've built. And we take a lot of care and time and detail really in sort of this development, and concepting phase around little details that create these magical experiences.

So for example when we turn on Jambox, we have this pretty cool sound design that go and that took, you know, months to come up with the right audio tuning. We worked with a lot of different choreographers to create that sound but every time someone turns it on I see them smile. And they laugh. The feel of the rubber prototyping and there's one manufacturer in world that was able to make the rubber at the quality and durometer that we wanted and the colors that we wanted for the first Jambox.

Right, so all of those little magical details how to resolve, even in software, right. When we had the first UP and when it plugged in and your sleep graph showed up. Even just the animations of how, you know, the bars would show up, and the way the cards would, would flow in and out. That was a detail that we had thought about, how's this going to interact, how's the user going to experience that, how're they going to feel it?

So this, a lot of that kind of stuff happens even at this stage where you sign off on a program it's going. But you're making those kinds of decisions all the way through and you're trading them off and you're doing it in the context of, of this bigger picture. So and continued innovation is an opportunity to keep refining, keep doing all that stuff so. So how do we think about it now you know it, kind of at a broader level, sort of what is the framework for how we think about these signature experiences?

Well we do start with these why's. Right, which is that articulation of a problem that we're solving. And then the themes around how these become actionable concepts, right? And then there's, there's what we do is we build these cross functional pods that take a person from the product experience team, a person from hardware engineering, a person from software engineering. A person from the data team, and we put them together and they're kind of person, this is the pod that owns that theme or that track.

And they continue to sort of build that out against the hero features and inside features and how we put that together. So, I'm going to go in now in, into more specifics around what we call these why's, because this is where I spend a lot of my time really asking a question. And what it does is it serves as a really interesting framework for us to be able to come back and say, hey do we meet those questions that we ask?

Does this thing actually do it? And it serves also as a really good guide post for a lot of our creativity and a lot of our innovation so that it's not unbridled, right? So, it really comes down to a very simple question for us. Which is, what is the user problem that we solve through this experience, whether it's in hardware, software, data, platform, whatever it is. That once we solve it people can't live without it, right?

They may have a absolutely burning need to go solve this problem and they can't, they're looking for a solution. Or it's things like, that once you have it you never thought you needed it, but now you can't live without it, right? And again, the Jambox is a great of example of that. We talked to some people when we were thinking about making that product, and it was interesting because...

Little story for you guys, when we launched the Jambox in the fall of 2010, the market for wireless speakers as a percentage of the overall speaker market was 0%, right, 0%. Last Christmas, which was you know, Christmas of 2013, it was 78% of the market, right. So in a few years we were able to transform this entire industry that'd been around since the 50s and 60s, turn it on its head.

And if I had gone out and asked a bunch of people and I said who wants, who wants $199 speaker for your mobile phone. I guarantee you that in that focus group 0% of those people would have said that I want that thing or I need it or that I'd be willing to pay for it. But yet when we did it, it transformed an industry, right? And so this is where these why's become super important, is just really focusing in on what you're doing, right?

And I'll go through one example in the audio space which is the Jambox example in the audio, and then I'll take you through a little bit of how we did it in UP in particular UP24. But it starts with what we call kind of our category strategy, and this is the sort of experience framework right? And, our view was, look, all of your content and media experiences are now on your phone.

All right, they are no longer on your iPad, iPod, or your computer. And so we need a different way to interact with it that needs to be as mobile, as portable, as high quality. All right, that was our, our fundamental thinking. And then we said that experience needs to be seamless across time and space, so anywhere through it, different car, you know, traveling, in and out of your house, around the house, that was fundamentally what we were doing and we said: that's the whole point of why this category should exist, right?

And that was the human problem. And then we said, okay, what's in it for Jawbone? Right, why should we do this? And so if you think about that broader macro context that I was talking around, the internet of things, for us, this was our entry into your home, right? And so while everybody talks about all these new things in your house from lights and thermostats and fridges and, you know, smoke alarms or whatever, being connected, media's still the killer app in your house.

It's where we sell millions and millions and millions of units, right? So we said, well speakers can be our entry into that world that's around you. And it can be the hub of things that we want to do from a software and service perspective in your home. So there's this interesting strategy at solving user problem, but then why does it matter to Jawbone? So those two have to go together because, A, we're not in, you know, philanthropic, not for profit industry, but B, this is, if you do this well, it allows you to keep doing great products, and it allows you to keep moving forward, and doing interesting things.

So that's sort of how we put that together. And then we built this sort of, what we think the experience, what we call the experience continuum is. Where is it today, right? And when we started it was a Bluetooth speaker, right? That was the core enabling technology that allowed us to connect to stuff. Where do we think that it's going to go tomorrow? And then, what happens when we can dream in the future, right?

And we start to really try to live in tomorrow and the future and the sort of think about what we build today as a stepping stone to graduate users starting in one place, continue to move, continue to move through that. And that gives us a view of how we also make these trade offs, right? Because we're not going to put this into this product, but we got a spacer in the next one and we know that we can move users to that and they'll be ready for it, right?

And that's, that's a lot of the way we build stuff is we sort of define that experience continuum right? And then it's, and then we, we do talk about this a lot. We don't think of ourselves as a hardware team or software team or data company or whatever it is. We think of ourselves as an experiences company, right? It's not just about that physical device or the feature, the object, it's about the system, it's about how the pieces come together.

And so when we start to define these whys, they become the problem statement, and we say okay, how do we use a piece of hardware. How do we use the service in the cloud? How do we use, you know, an application, a sound, a button to solve this user experience problem that we have? And what's the right distribution across that system of where you should attack the problem, right?

And where do we need to innovate? And where do we need to pull together? So that's a big, big, big part of the thinking. It helps us do it, right? And, you know, it's when we think about these here experiences, right, we say it's really around the context of why it's magical to the user, right? And then like I said, the system is a flagship, and then it has to go to the level of emotional connection, right?

Where you feel without it you're lost. Like, I'm going to go back home and get it if I don't have it, right? And so those are the kind of principles that govern all these things. And we have to keep asking ourselves those questions, is it doing that? So we pull this all together in experience framework. This becomes essentially a brief for your engineering team and your design team, and all the people that work on this in the company.

That they can go back to and say, what are we doing, and why are we doing it? And how does that work? And then how do we create against that, right? And then we have a sort of whole process, Blueberry is one of the internal code names. But the user experience process starts with a better resource, so we do actually listen to users and talk to 'em.

But we talk to 'em in a very specific way. Start looking for those key insights. We concept 'em and then we start to build, right? And this is why we go to find those lists of consumer problems. The principles, how do we think about approaching that? What are the solutions? And then what's required in the product to make that happen. Sam? >> Could you talk about how you balance the fact that a user would never told you they wanted to pay $200 for a wireless speaker with user research in front of this process.

Yeah. Well, there's two different, there's a lot of layers to users research, right? So what we look at, that's a great question. So you guys probably aren't familiar enough with this yet, but there are sort of standard tools for what people do in focus grouping, where they say, would you try this, would you do, would you pay this, do you want this feature, do I want this feature, what do you care about.

That's one way to do it. And we don't usually get there is really great answers. We ask different kinds of questions. We say, you know, how much music do you listen to when you are with other people? How do you play that music? Do you listen to a headphones, or do you listen over the speakers on your phone? How often are you with other people? How often do you want a personalized experience?

How often do you want to share?... So, we ask, like, we ask a lot of questions. We just ask different ones. And we don't ask them specific things about do you want this or do you want that. We ask them: how do they behave? How do they live? And you say to them, hey, if you had something that allowed you to take, you know? A great example is iPod.

If you said to somebody, if you could put a thousand songs in your pocket and take them anywhere, that's cool. Not do you want a digital portable music player that, you know? So again it's, it's at a price that was, you know, more than your phone, right? So, you sort of have to separate what are questions that you can ask that are going to help make you smarter about your thesis versus trying to get somebody to validate it for you, right?

And I think that's the real separation. Is it's that, no one's going to tell you what to build, if they do then they should do it, not you. And so you, you're the one who's making that decision, you've got the thesis, you've got the creative idea, you've got the innovation. You gotta use these people to help you make it better and to refine your thinking. That's the difference.

Make sense? Okay. So, I'm going to switch over to some Up24, which is the product that we've had on the market, our wireless products for health tracking. And the whys of Up24 are really simple, right? Well, first of all, let me start with the whys for Up. The idea there was there's so much that we know about the world today, through Twitter, Facebook, social media, access to the internet, Google, et cetera, but we know nothing about ourselves.

We have no idea why some days I sleep eight hours and feel terrible some days I sleep three and feel awesome. Like I just have no idea, right? And so I, our thought was: could we take a lot of this sensor technology, help people understand more about themselves and start to then make better decisions about how they live better. So this, that was the first product. This was the second product we said: Okay, Great!

Now that we have wireless connectivity, it's not just about Bluetooth or wireless, it's about the fact that I can use that real time flow of information to understand what's happening with me, and go take action on it, right? I can get the data in a more meaningful, relevant, contextually important way at the moment that it matters. I can also get back guidance in a structured way that can help me go do things.

And I want that ongoing encouragement, because everybody, you know, knows that they want to be better, but they fall down or do whatever. And they want to, a fluid way to interact with this. So this is what we, we're sort of building in Up24, right? We had this very crisp set of five things that were the whys of why we're building this product and why we're doing it.

And our point of view was that it was going to, we had this sort of fundamental narrative going, going back to the experience framework where we said everything we do in UP is about, you know, helping people track and understand them, track themselves, was understand, which is taking all that data and converting it into knowledge. And then the third part was act, so track, understand, and act.

That is our narrative for everything we do in the, in the kind of wearable health space, fundamental. And, and it will be for, for the entirety of what we do. It's sort of, help people get more information on results. Data is great, understanding is better, convert that into things that they can, have, create real knowledge that they can then take action on. So anything that we can do to keep the device on, get more information, help them be engaged and then find ways of, of guiding that behavior was really, really interesting.

And this is the sort of framework for the system. And then you can start to think about, well, that designs how you build your data infrastructure, your insight system, how you process it, how you build the application experience that surfaces it. And this is a little bit more of a blowout around track, understand and act, right? So we got it in and, and this is, the, the tracking part is really fundamentally about the hardware too.

It's sort of, how do you design the batteries? How do you design the embedded systems and materials? The way it latches on you. How easy is it? So that you keep, create the habit of keeping it on your body, right? Then you gotta take all that data, and it's not just visualization of information. Like, you know, if I told you you guys' heart rate was 75, is that good or bad?

Who knows the answer to that question? I don't. It depends, on what you're doing and who you are and, and what's happening. So just the data surfacing is not enough. You gotta contextualize why that matters, turn it into action. And that's the third part, right? Is action is the key. So let me understand the data. Let me understand that when I work out at four o'clock, I get four more hours of deep sleep at night.

That's awesome. So let me get a reminder at four o'clock to go work out, or do whatever, right? And that's what we've built. And that's a lot of infrastructure to sort of create that experience. But that's how we build software. That's how we build hardware. That's how we build sort of the whole system. And then often, we, we will talk about different kinds of users and what they care about and what we think our user base is made of, and who's more into weight loss, who wants the sort of social acceptance, who are people who are vain, that just want to look better.

And why it's true. So, you know, there's lots of different things. And we, and there are people who have sort of medical reasons for the use of our product. And we design different kinds of experiences, right? And we think about using.. the platforms like the phones and ways to push notifications and as part of the system think, right. We think of notifications as a tool for behavior change, right?

And the we actually start to go map out these things. What is a smart action? Right, is it real time, is it feel customizable, does it feel progressive, does it help me, is it really tailored to me? And then for this particular type of user, we'd go out and storyboard and then, these storyboards go to our design engineering teams. We work together and they actually start to build off of this.

And what it does for us is it creates a nice set of constraints. My experience has been constraints are really great because they serve as opportunities to resolve, to refine, to simplify and push you to find the right answer that it will solve the user problem in the simplest way. And so we, we create a lot of those constraints around what we're doing. This is this is the, the sort of storyboarding for, getting someone to the goal, and how they do it and what we use in real time.

So,.. and then we put in sort of the secondary experiences right? Which is if we can do this and we can fit it in, it's not too cluttered or confusing we'll put it in. So that's a little bit of a snap shot into how we build and we've few minutes left so I'd love to answer any questions. >> Yeah, questions are great. >> Yeah. >> You got about 15 minutes.

Good. >> So, let's say you have this product right, you have all these features that you want to do right, all these things, to satisfy and you're into your design process right? How do you approach the whole problem? How do you break it down so that it's all business? To satisfy, you know, this problem in this way, right? But then, cause each design feature is not mutually exclusive.

How do you project holistically? Sort of that problems... >> Can you repeat the question for the recording? >> Yeah. So I think the question was when you have a number of different features and functions that you're trying to build, how do you look at it at a system level to understand not within that one silo what the trade offs are but what the trade offs are across the entire system?

I think that's the answer to your question. You do exactly that, you don't think about it in one silo. You have to force a lot of, you know, when it's a small team, it's really easy because you guys are all sitting around the table. You're looking at each other. You're making those decisions in real time. As you get bigger and a larger company, you have to force a lot of communication where everyone is in a room and they, that person says, you know, what if you build, if you were contraining this way, then I can't get the quality spec that you need me to make.

And this guy's going to say well, if you do that, and you give me that much space, then I can't fit all the algorithms in at the battery performance that you want. And so when you start to look across the system, you start to see everyone has to share what their pains are. And they actually don't understand. If I make this tradeoff, it's going to affect me over here.

And so you have to put them all together in a room, and start hashing that. But what's on the board and on the walls, and on everywhere, is what are we trying to do? And does that, does that tradeoff still meet it, right? Across all those, all those different silos. Because everyone's thinking about the tradeoffs in their and they know what they need to accomplish, right? But again, it is how does that affect the whole thing.

We just went through this with UP3, which is a product we are shipping in a couple of weeks that sort of defined the next wave of what is happening in the wearable space on the health tracking side. We invented a totally new sensing system, right? There was RAW science that had been developed that we productive really fast, and even just trade offs on what the electro materials were.

How it affects on reliability, sourcing, you know, signal performance. And these guys weren't talking to each other. We had to get in a room. Do daily calls for three hours, where they're going thru each of their things. It tedious, but we're figuring it out. We knock it down. So it's a little. When you're small it's really easy because your just look at it. But you have to always have that definition of what you're trying to do across the system, and that's why a lot of what I was talking about was much higher level.

What problem are we solving? Where's it go over time and then how do all these pieces inform it? Go ahead. >> If a startup wants to build a system eventually, should it start focusing on one small thing or should it start looking at systems itself and how to do them altogether? >> How do you get, I think system think it's a way, it's a mindset. It's not actually a system like the simple systems, there are complex ones.

You know, a plane is a very complex system, a car is a very complex system. There's other products, we make that a more simpler phone as a complex system, an application, you should think of as a system. And how all the pieces work together. Your storage, the fun and experience, what you're doing, the connectivity, that's all a system, right? And so that's more what we mean about system.

Yes, for us, system is hardware, software and data but I think within even anything, there's always system things. And so it's more just thinking about how trade offs work across all the different pieces as they come together. Does that make sense? Go ahead. >> I have a question. What's the decision making process between creating like related products in the same space? Like for fitness tracking, there's different versions of, for, for Jambox.

Use different versions of Jambox. And, you know, what goes into that? >> We do have a grand unified theory, at some point, around how these experiences come together. And what happens and it touches a little bit that point that I was making to you around. A context engine, when you have things on your body that can make everything in the world around you smarter. Like if I know the emotional state of a user, I can tell Spotify what song it should play you on the Jambox, right?

I can tell the TV that you didn't like that commercial, they should fast forward to the next one. Or I can tell you not to watch Game of Thrones on a Sunday night, because you don't sleep well. And so you start to see I'm serious, right? And so these pieces start to, to go together. And so we do think at that level, and then we start to say what are the building blocks that get there?

Now how do we establish credibility? How do we establish a distribution system? How do we establish manufacturing scale? How do these pieces start to come together? So there is a grand unified vision for us. And we look at different categories and different categories have different dynamics. They move at different paces. They have different replacement cycles. A great example of this right now is what's going on with iPad and iPhone.

We're all very used to replacing our phones every single year. iPads are not following that same trajectory, right? So the replacement cycle is different. The use case is different. The problem its solving is different. So you've gotta adapt to that, right? You don't replace your nest every year. It's a 15 year install, so how do they build in that kind of a world and how do they think about...

So it's just, you gotta think about your category, the replacement cycle, the usage, how these things come together and, and the dynamics are different. Go ahead. >> First of all, how you would canvas of this at Jawbone? I mean the user buy one, why did they pay? And it's better design, you have this idea, or you think the functionality is somewhat important? >> Which piece are you talking about?

You're talking about the texture? >> The texture, yeah. Need a texture. Succeeding at every job and product. >> Yeah, I know. A lot of that was developed by Eve and design team. And, and sort of, you know, coming up with a branded look. So you saw the icon and you knew what it was, right? Whether it's here or, or anything. So that was part of our mission.

We wanted to convey a certain emotional quality, etcetera. Some people like it, some people don't. That's sort of the nature of the design. But that was all part of the same process. Go ahead. >> Sorry. >> Nevermind. >> Yeah, so. This is kind of going off of the other questions. But when you get a certain product, how does your processing unnecessarily changed, and how do you take into account information you might have learned from, let's say, like,.

Like how does the framework and processes work? >> It's a good question. I'm actually going to go back to that. So the question was, it's sort of not on the initial product, but as you've launched the initial product, what happens to your thinking and how does that evolve the process, right? So I'm going to, going to take it back to that slide that shows the kind of the how we create and the process flow, right here.

So... Sorry I gotta go through these builds. So it's actually a great question. So say this is you're starting something totally new from scratch, and you come out here and you do all this stuff and you get it to here. And then you learn a lot. And in the first iteration of Up, you know, in 2011, it broke. It didn't work. So we had to actually go back to the drawing board.

And so what that did here is we actually ended up telling these guys a bunch of things that they should be thinking about and sort of unlocking a lot of problems we had to solve. That they then started working on it at a different pace because sometimes this will take years to come to fruition. We can dream a lot faster that what's possible, right? And so even at core technology levels, its sensors, batteries, I mean, chips, right?

You know, processing. What we can do with storage. Like, all that kind of stuff. We'll say, well you know what? Those are the problems that we're facing, what if we start running parallel threads to go fix that. And so we'll start doing some work here. They'll look at it in different parts of the process. So there's room for innovation in all these different things. But we may see something here that we say Let's go straight into planning and development.

We don't need to go all the way back, right? So we have the flexibility to sort of jump through and say we don't need to do these things. We know that.... Like it wasn't a big struggle for us to know to go from a solution to plug in to go wireless. Like I wasn't concerned that we had to a lot of concept evaluating. So we can kind of skip through those steps if you know how to make those decisions.

But this is more for us in a lot of ways is a way of kind of taking a lot of innovative spirit and creativity and giving it a very focused way to actually get out. And so that's what we think about. We have the ability to sort of go back and forth and skip over steps as necessary. Go ahead. >> I'm just curious how large is in terms of the number of employees and then as you've asked more employees what were some of the kinks that you encountered of having you know, not just a group of five.

But more people working on one project, and then everybody getting heard, or some organizational tools to facilitate that. >> Yeah. That's a good question. So the question is how big are we. And then as we grew from, you know, few to many, how did it change our thinking around process and tools and how we kind of work together, right? So we're about 500 people and we have a very remote setup.

We've got an office is Sunnyvale, headquarters in San Fransisco, offices in Seattle, Shanghai Pittsburgh, London. And so we have a very you know, distributed team that poses a lot of interesting communication zones. But also allows us to get where the talent is, and where there are interesting people in specific areas that we're doing. I would say the single biggest thing that, that we continue to always try to get better at is that communication between all these different people.

Working in different ways and forcing them to sit at the table, and say, here's what I'm working on, here's where my tradeoffs are. This is what I think it should affect you. Listening to other people, and sort of understanding it. And then remembering that we are building this system and here's what happens when all the pieces come together. And then, how do we, we solve problems? But it's a lot of that, forcing that communication.

And doing things like, I, I, literally on UP3, have a daily call that's two and a half hours with the entire team, from materials, sourcing, manufacturing, design sensor, firmware, mechanical engineering, all together. And they all have to sit through each others updates and but then understand what those tradeoffs are and I sort of for, force that communication. So go ahead. >> At what point did you decide to expand?

And how did you decide where to expand to first? >> Question is good. So the question is, how did we decide to expand and when? Are you, is that geographical, is that our team, was that markets? >> Yeah, how did you find the connections to each other in the other...? >> I think a lot of it some it's deliberate. We sort of say obviously we, we build a lot of things in China, so we need to have a presence there and manage things.

So at some point we got big enough that we wanted our own team on the ground. You know, we've expanded sales. I think we're in 56 countries globally, 100,000 points of sale. So that was, you know, we started in North America, we went to Europe, we went to Asia. Now we think a little bit differently about when we launch what geographies we go to. So it's some of it's deliberate and planned, some of it takes time.

And again, it's part of that, you know, we want to be here, here's how we want to grow, we want to migrate our business this way. And then a lot of it is also opportunistic, right? There are markets that we've entered where you know, we had a really good partner. We had a really, you know, strong proposition. The, the culture was really well suited to what we were doing.

We, for UP, China's a huge market for us. We went in with Apple in, in Apple stores. And that was a great stamp of credibility and we sort of rode that wave. So, again, but we knew we wanted to be in China, and that was a great entry point for us. So I think it depends on what you're doing specifically and what's appropriate for that situation. Go ahead.

Why haven't you made any headphones? >> I mean, for us, like any category, I get asked about a lot of different things, headphones is sort of one. First it's like, you know, when we come into a space, we want to blow it wide open and make sure we have a proposition that makes it better for the user than what's there today. And make it better in sort of a order of magnitude or two order of magnitudes and do stuff.

So, sometimes the market's not ready. Sometimes the technology base isn't ready. Sometimes we're not ready. We don't have the right capabilities to synthesize and pull those pieces together. So, it's a combination of factors whatever the product or the category is, all right? >> All right, one more question. >> Go ahead, in the red sweater. >> Hi, for a hardware company or a system company the product in recycle is always a headache.

Sam mentioned one early faculty who had tried to run a hardware company and a software company and I was wondering is there anything you can share there? Are you trying to run JawBone more like a close a software company to get user feedback along, along the way or along the process? >> So I think the question was hardware companies are sort of hard to run, they're different from software companies.

How are we trying to run JawBone, right? I would say there's no model for what we're trying to do. It's never been done before, so we feel like we're at the tip of the arrow. We're putting together disciplines that have never had to work side by side to create experiences. It's very painful sometimes. It's very fun. We try to take the best of everything. Try to take the best practices of what make, you know, rapid software iteration.

Testing and development, deployment, try to apply that to hardware. We try to take the resolution that you require in hardware and apply that to software design, because web software is very different than mobile software. And it turned out that building mobile software was actually a lot more like building hardware. Where you actually had one shot and you had to get it right right out of the gate.

So, we try to take the lessons from each place and make ourselves really good. And that's my job and that's the job of some of the other senior leadership is to look at those opportunities of how you kind of take the best of everything and put it together. But I don't think there's ever been a company that's been equally great at hardware or software data. And that's what we're trying to do.

Thank you very much. >> All right. Thank you guys.