Fragments of Ricocheting Thoughts

Apple v FBI isn’t about security vs privacy; it’s about America’s security vs FBI surveillance

mostlysignssomeportents:

Dan Kaminsky, one of the Internet’s essential squad of “volunteer fire fighters” who oversaw the largest-ever synchronized vulnerability patching in Internet history, has written a stirring editorial for Wired explaining what the FBI puts at risk when it demands weaker encryption: it’s not our privacy, it’s the security of finance, health care, roads, and every other piece of tech-enabled infrastructure in the land.

Instead of fighting to make crypto stop working, the FBI should be fighting to make it as good as possible. They should be establishing a “Cyber UL” that helps Americans figure out whether the products, devices and services they use are secure. They should be fighting fires, in other words, instead of setting them.

http://boingboing.net/2016/03/02/apple-v-fbi-isnt-about-secur.html

(via kenyatta)

After reading"What is Amazon’s approach to product development and product management?“

lbw8806900:

After reading the article “What is Amazon’s approach to product development and product management?” I totally understand why we need try to use a approach which is called"working backwards"to get strat for our personal $1000 project. It makes a lot of sense. Actually, I had some personal experience when I as an industrial design student.

Here is a story I want to share. I still remember that when I was in my second year of college, I devoted myself to take part in different kinds of design competations in order to prove myslef. During that time, everyday I just looked for different types of unsolved or unserved problems without too much researches,there is no need to say write down something like press release, all I did was tring to give a quick but permanent solution.(Sometimes, they are not a real problems but I just strong believe that it is!) After spent a few minutes to make a desicion and then spent next few days to excute it , built the 3D modeling and rendering , use some technologies or the terms to describe the idea which I didn’t even understand it. I felt very satisfied and excietd with my work when I made some really cool modelings or renderings, I thought now I’m a designer and all what I did for my project is about design, every time when I finished my work, I’ll show it to my classmates and my professor and strong believed that everybody will like it, appreciate it when they saw my work. But when I herad people’s feedback, suggentions or differnt voices which I thougt is cool, I just brought my work back and added those new functions directly based on the previous one without any filter which I called it “iterate”. Because of that, even though it was a real problem with a great idea, but excute it along the wrong development process I usually did overdesign which lead to a bad output.

This is the reason that why I totally agree with : “Once the project moves into development, the press release can be used as a touchstone; a guiding light. The product team can ask themselves, “Are we building what is in the press release?” If they find they’re spending time building things that aren’t in the press release (overbuilding), they need to ask themselves why. This keeps product development focused on achieving the customer benefits and not building extraneous stuff that takes longer to build, takes resources to maintain, and doesn’t provide real customer benefit (at least not enough to warrant inclusion in the press release).“

It’s worth considering Amazon’s product management philosophy in context of where they are as a company. Amazon is huge, and focused on incremental expansion of its product offerings. Product directions are set out from upper management, and so this process enforces that focus on the company’s strategic goals.

Likely at the expense of serendipity.

I look at the Fire Phone as an exemplar of “Press Release Driven Product Management” gone awry. I suspect that most of the things that was on that internal “press release” got into the release, at least, on paper. The cohesive user experience got lost in the process.

Which isn’t to say a “press release” isn’t useful – it is very effective at driving focus. If focus is what the company/product/team needs right now, great. If not …

The case for H2O

TL;DR: Why I am joining H2O. This is long and rambling, and mostly written for myself so I can review it in a year or two.

Today I start a new role at H2O, a machine learning applications company with a open source platform for data analysis. Three years ago I wrote a blogpost about why I chose to work at Sift Science. This blogpost is similar: this is my hypothesis for why H2O is an interesting opportunity. I thought about it from the following lens:

• Company Mission
• Team
• Learning Opportunity
• Unique Contribution

I will focus mostly on my rationale, but I will also add a few pre-mortem notes.

Company Mission

As I understand it, H2O is a “tools” company. They focus on making really great machine learning software, which data scientists and engineers can use in applications they are building. The way I explained the difference between H2O and Sift Science was this: if Sift Science created cars (i.e. a full featured product designed to solve a specific problem for customers.) then H2O makes engines.

There are many companies with this business model – make tools available for free, charge for services and consulting. What makes H2O interesting? To me it is the company’s thesis about the future of data science and data analysis.

Today, in order to do large scale machine learning and data analysis, you must first understand statistics and modeling. On top of that, you must also understand distributed systems engineering. Why? When a data set is sufficiently large, it is infeasible to perform all the computation on a single computer. It’s simply too slow. The solution is to split up the task and have multiple machine perform the task at the same time i.e. distributed systems. This is why good machine learning engineers are so hard to find. A suitable candidate needs to understand both distributed computing and machine learning to do their job well.

What if that’s not necessary? Machine learning and data analysis does not intrinsically require understanding distributed systems. If we can remove the distributed systems engineering requirement, then large scale data analysis will become accessible to a lot more people. There are an order of magnitude more data scientists and statisticians out there than there are machine learning engineers. These are the people who will be enabled by H2O’s software to run analysis they had never been able to before.

Frankly, I can’t wait to see what creativity this will unleash.

Pre-mortem: I can see a few ways things might go wrong,

• Abstracting away distributed systems proves impossible, or the abstractions will prove too leaky. In this case, H2O’s software will still be valuable, but will not be paradigm-changing. The status quo of big data analysis requiring engineering+statistics “unicorns” remain.
• Abstracting away distributed systems proves too easy, and competitors are able to quickly replicate this ability. In this case, H2O will need a different competitive advantage.
• The value of data analysis pipelines resides not in better algorithms, but in better feature extraction, and therefore competing to be the best ML package is futile. Frankly, this is the one that actually worries me most. ML packages can compete on speed and accuracy, but both of those traits have diminishing returns. As I witnessed at Sift Science, real world prediction gains comes just as often from improvement in feature extraction as from algorithm improvements.

Team

My first connection with H2O came through Erin Ledell. This was after R2D3 came out, so naturally talked a bunch about how to communicate machine learning insights to a broader audience. Through our conversation Erin’s passion for good open source software clearly shone through. She really wanted good tools to be accessible by as many people as possible. As I met more folks from the engineering team, it’s evident that this passion is shared by many at the company. The theme underlying every interview question was, “How can we make this software better? How can you help us make this better?”

In addition to a passionate and sharp R&D org, I was also intrigued by my conversations with Kanishk. He is the VP of Customer Applications, and we had an interesting and wide-ranging chat about how H2O’s software might get used. The most interesting insight from Kanishk was how algorithm speed opens up new frontiers. I was reminded of the maxim about how the abundance of a resource leads to more imaginative uses of it, and my mind danced with ideas about using machine learning for art.

It was clear that H2O has put together a really impressive team.

Pre-mortem:

• I may get silo-ed as a data-visualization designer in a engineer centric organization. While I am glad that H2O reached out specifically because I demonstrated that I can communicate machine learning concepts with R2D3, that doesn’t mean the whole organization understands the value of product design. I guess I was worried about this when I joined Sift too, but that worked out fine.
• I will have difficulty nurturing design culture there, since the culture of H2O is largely already set. I joined Sift Science when it was eleven people. It was much easier to have a personal relationship with everyone who was there, simply because I was there while the organization grew. I made it a point to explain the role of design to everyone when they started. My influence will be much more diluted at H2O, which already has 50 members.
• Everyone at H2O seemed super focused. One of the things I really enjoyed about Sift Science’s culture was its emphasis on work life balance. I didn’t really probe the culture at H2O as much as I should have. Other than a really smart and focused team, I am not sure what I am getting into culture-wise.

Learning Opportunity

I have an draft of a blogpost called “What comes after the Triple Threat Designer” where I contemplated what kind of skills I should develop next. My personal career thesis was to be fluent in design, technology, plus product strategy, and to create a unique blend of capabilities from those disciplines. At Sift Science I was able to prove out that this blend was in fact effective, especially in these two situations:

• Making design decision while taking all three perspectives into account.
• Vetting and refining ideas from various parts of the company into feasible projects.
• Translating ideas across functional boundaries effectively.

At H2O, I want to add data science to this mix. Thanks to working at Sift, I have developed a particular affinity for data products. I learned a lot about the in’s and out’s of machine learning, and saw how machine learning systems gets deployed in real world applications. At the end of the day though, I was designing for fraud managers and analysts. In reviewing my various hackathon projects at Sift, I found that half of my projects were tools I built for Sift’s ML team. These were often the hackathon projects I enjoyed the most. At H2O, designing tools for data scientists will be one of my primary roles. Given the range of customers that H2O has, I have the opportunity to see a broad range of data science teams and processes. My goal is to use this opportunity to develop a unique perspective for designing data products, and become a world class data product designer.

Pre-mortem:

• If I mess up this opportunity, it will because I get too caught up into building “cool” things, and do not spend enough time actually talking to customer and clients. I know I have the tendency to obsessively polish a project, which worked well for R2D3, but will serve me poorly if it takes away from learning from actual users.

Unique Contribution

There a lot of product designers out there. Many of them have front-end engineering chops to bring their designs to life. The pool starts to narrow if you want the product designer to have a data-visualization focus. Of these, very few are also familiar with machine learning and data science. H2O is looking for exactly this, and I am fortunate that my skill set and interests are such a great fit. H2O aims to be the go-to platform for open source machine learning. It has already developed a great set of tools algorithms, and a track record for solving real business problems with them. To broaden adoption, it needs to improve the usability of this tools, and help people understand their results through data visualizations. These are things I have done before, so I am confident that I have the right set skills to push H2O’s product to the next level.

Pre-mortem:

• This data+design+product synergy may be overstated if the needs of the company turns out to be more simple. e.g. if lots of individual data visualizations needs to be produced independently of each other, and customers don’t find it important that they are cohesive.
• This synergy is not scalable. This I already know is true. As companies get bigger, roles ought to become more specialized. As H2O brings in more specialists, folks with hybrid skill sets either move into management, or find their opportunities diminish. A company at H2O’s size should be starting to hire more specialists. I am not sure how this will play out.

The Point of a Pre-Mortem

Folks often complain to me about the morbidity of ‘pre-mortems’ – but to me that’s exactly the point. I am really excited about H2O, but I want to make sure I remind myself that failure is always a possibility. I don’t think I am a pessimist. I know most of these ‘pre-mortems’ likely will not come true, but it is important to articulate it before hand, so it can be a point of reference for review later.

As I was writing this post, I went and reviewed my pre-mortems for joining Sift Science. Essentially all of them were unfounded worries. I had a very happy two and a half years at Sift. The only one that was remotely accurate was the one about “wanting more variety.” It took 28 months before I even starting thinking, “oh maybe there are other interesting problems out there. I should go out and look.”

Anyway, here’s to a new beginning. Let’s see how this plays out.

Sift Science: Lessons Learned about Building Design Culture

TL;DR: Building a design culture in an engineering centric organizations requires designers to first seek to understand, then to be understood.

1. Good design requires non-designers.

Designers can put together mocks and prototypes, sketches and wireframes. That doesn’t really count as shipping – not without engineers writing code, product managers writing specs, marketers writing press releases, sale folks showing demos, support team educating customers. A well designed product is delivered by a whole team, through a collaboratively built pipeline. If folks along the pipeline doesn’t understand the value of design, some part of the customer experience will fall through the cracks.

2. Learn your counterpart’s Language and Motivations

Engineers want clean and maintainable codebases. Sales folks want a easy to explain and attractive product. Marketers want a coherent and relatable product story. Support teams want well documented error states and messages. Everyone wants to serve customers, and all of them measures their success in their own lens. Design isn’t necessarily top of mind, until and unless you can frame how design helps your teammates succeed in a way that they can see and understand.

Getting your teammate to see the impact of design is therefore itself a design problem.

3. Give non-designers a framework for thinking about design

… or at least a framework for interacting with you. Start with the basics of empathy, e.g. 

• people have short attention spans (therefore products must earn their attention)
• people have pre-existing mental models for understanding their problems (therefore frame ideas in customers’ existing mental models where possible)

And the basics of the design process, e.g.

• It is iterative and intuitive (so trust the process and keep at it)
  
• practice beats theory (so prototype it and show it to customers, then listen)

Help the team understand that design is not colored pencils and magic, but a deliberate practice of making products fit how customers understand/solve their problem.

4. Build a network of design-minded non-designers

Give your framework to everyone who would listen. Not everyone will, but with just a few people on each team with this mindset, it will become a lot easier to deliver good design. You won’t have to run around advocating for design yourself, you will have nurtured advocates.

Keep that network going. Check in with your new, distribute (across functions) design team. Your sales designer will pass along customer feedback. Your marketing designer will come up with new product framings. Your support designer will find and patch (!!) edge cases you never thought of. Your engineering designer will tell you about new possibilities that the new stack is about to unlock.

5. Start with conversations

All of that sounds like a lot, but it doesn’t need to be. It just needs to start with conversations. My go-to opener is, “How are things in Marketing/Eng/Sales/whatever-land?” then followed up with attentive, inquisitive listening. People love to be heard, and people love to help. Both of those things happen more often when conversations are happening, and when people feel that a relationship has been established.

End Notes: Tactics for Building Design Culture

• Jump in on other teams’ needs at hackathons. Every hack I’ve done at Sift were for one team or another. It helps build credibility, and shows that you actually care about your counterparts’ success. It’s also a great way to demonstrate the value of design applied to their problems.
  
• Run regular, open-to-all design critiques. An open design critique is one of the best way to demonstrate you value feedback. In the beginning it is necessary to establish ground rules about what kind of feedback is sought, and how feedback should be structured. It also requires more preparation to frame presentations for non-designers. Once that practice is established however, it models a pattern that spreads outside of just these critiques. 

A Fond Farewell

TL;DR: Today was my last day at Sift Science. It’s been a heck of a ride, and I’ll miss the team dearly.

I joined Sift two and a half years ago, when it was a small team of mostly engineers in a small office just above Market and New Montgomery. A really talented, really humble and really hungry bunch, looking for a data-vis oriented designer to go along for the journey.

I barely knew anything about machine learning. I knew nothing about online fraud. I had never done b2b design before. I didn’t even think I was done living in New York. Yet, it was an interesting and compelling enough risk that I had to sign on. There are lots of writing on start-up experience – the grind, the up and downs, and fiendish puzzles – but reading about it is nothing like experiencing it.

That’s not to say there wasn’t grinds and ups and downs and puzzles. There were plenty. Accidentally great designs? Check. Blotched launches? Check. Hard won product insights? Yup. Design culture drip campaigns? I like to think I won some of those. I even somehow got a whole component past code review and merged.

The much stronger impressions though will be the team. Credit to Jason, Fred, and Liz – Sift Science has built a team of kind, humble and collaborative people. Folks respected and worked on the level of ideas, not personalities. Teams respect one another across functions, and reached across for feedback and support. It was that way when I joined with 11 people in the office. It is that way when I left today with 40+ folks. It’s hard not to be friends with people here – and I know for sure that many of my friendships here will endure.

So Sifties. Thank you. I leave with distinct notes of pride and pre-nostalgia. Sift Science is a good place. We did good work here, thwarted a bunch of fraudsters, helped build a good close knit team. There’s just so many lessons and memories and friendships I am privileged to take with me. I can’t thank you enough.

I’ll come visit often. I promise. Until then, take care, and keep it up.