Eli has dedicated his career to figuring out how technology can elevate important topics in the world as an author, an online organizer, and most recently, as a co-founder of Upworthy.
This year, I had the pleasure of speaking at the Lean Startup Conference.
I spoke about the difficulties we all face when getting a product out the door — namely, that we are worried we won’t get it right the first time, and that our reputation is therefore on the line.
In my talk, I shared my own story about becoming a better product scientist, and how that helped me get over my fear of shipping imperfect products. I also shared 9 tips on how to be a better scientist when shipping your own less-than-perfect product.
Below, I’ve shared the video and the slides from the talk so you can take a peek!
IBM looking to repurpose laptop batteries in developing countries
Spray-on solar panels
Microsoft now accepts Bitcoin for xbox
Apple accepting paypal online in the US and UK
DriveMode – use your phone without looking while driving
Toronto gas prices down to $1/litre
Alibaba CEO tops Forbes China Rich List
Baidu set to invest $600M in Uber
Facebook thinking about adding a dislike button
Friday: Photoshop your face
Photoshop your face for $5 at lunch today to help buy goats for families living in poverty
No More "Ghost Nets"
Lost and abandoned commercial fishing nets ("Ghost Nets") may be a thing of the past. Engineering student in Spain comes up with an RFID tracking system to reduce their occurrence, and a net that biodegrades in 4 years just in case they are lost.
Apple and IBM Partnership
Apple and IBM released their first wave of mobile enterprise apps.
As the Internet of Things (IoT) expands, tremendous amounts of data are being generated by real world devices. Data science and machine learning techniques are extremely useful for people wishing to make sense of this data. In this video, Nitin Borwankar talks about LearnDataScience, a series of IPython Notebooks designed to teach data science to developers.
Physical Fitness Claim Form
Fill out this form to claim your fitness benefit:
Android Studio 1.0
Android Studio 1.0 released
Amazon Threatens To Move Its Drone Research Overseas
Flickr Selling Creative Commons Photos As Wall Art
Bots Watching And Clicking Ads Make Up Nearly 25% Of Ad Hits
Congratulations to the winners of the Goodlife Fitness Raffle
Congrats to David Nicholson, Evie Sun, and Alexander Chong! Please go to HR to claim your prize.
You heard about it…you’ve seen designers huddled in a room, pointing at things and placing dots on print-outs. But what are they doing in there? And why are they doing it?
WHAT IS DESIGN CRITIQUE?
It’s time set aside weekly for designers to present their client work and collect feedback. Designers pair less often than developers do, so it’s important to have designated collaboration time and input from the whole team. In our design school days, we used to get constant feedback from teachers and students. This scheduled crit time was an integral part of learning and honing our craft, so we decided to incorporate it into the design practice here at Pivotal Labs.
HOW DOES IT WORK?
We meet every Wednesday after lunch for one hour, broken down into two 30 minute slots. This is enough time for two designers to present their work. I informally reach out to the team via email at the beginning of the week and ask if anyone would like to present anything. Most times we have two people, sometimes we have one, and other times we don’t have any.
WHAT IS OUR PROCESS?
The first designer pins mockups to the wall and projects them on the monitor for the team to get a closer look. Sometimes they click-through and project a prototype as well (if they have one). They start with a brief description of the project they are working on and the design problem they are trying to solve. They also state what kind of feedback they are looking for, whether it be strictly Visual Design, Information Architecture, User Experience, workflow, etc.
After the intro, the team moves around and places dots on areas of the mockups that they would like to talk about. These dots tend to form a heat map that highlights any red flags, problem areas, or elements that are working. They also capture corresponding notes on index cards to help them keep track of their thoughts. It’s important that we focus on the problems, not the solutions. We leave the solutions up to the designer, since they have more context—and it would be unfair to rob them of the fun part! We do this for about 10 minutes, and afterwards a proctor leads the discussion.
The proctor is tasked with surfacing all the feedback in the remaining time. They use the dots to guide the discussion linearly, while offering suggestions and clarifications along the way. Because dots have initials written on them, the proctor can call on people and ensure that everyone gets a chance to contribute. The team discussion lasts for the remainder of the session (about 15 min) and at the end the designer keeps the dotted mockups and corresponding index cards to either share with the client or incorporate the feedback into their workflow (or both!).
Designers get the help they need and the leverage to act on it. Critique helps them decide between different approaches to a problem, rethink layout and workflows, and choose topics for user testing. The weight of the team’s opinion validates the designer’s direction to the client. They can go to their client after a session and say, “I just came back from Design Crit and the team was really excited about option A! Let’s try that!” It helps to validate ideas with the rest of the team, and reassures the client that other experts have come to similar conclusions.
Design Crit has goals that span across the project, designer, Labs design team, and the client. It keeps the project healthy and opens the doors to fresh eyes and further clarity. It gives designers an opportunity to get more eyes on their design, and it’s good practice for learning how to receive feedback and not take it personally. It gives the Labs design team exposure to other projects and the opportunity to give constructive feedback that’s not solution based. The client gets access to talents outside their allocated designer, and it provides talking points and validation for stakeholders.
Labs designers aren’t the only ones at Crit! Clients, Product Managers, and Developers have joined, and have even presented! We also have had prospective clients and designers in the community sit in to observe, share, or learn more about the Pivotal Labs Product Design practice.
COME TO CRIT
Do you have designs you’d like some feedback on? How about a dev-only project that is in need of some design direction? Come to Crit! Email me at firstname.lastname@example.org to set up a time to sit with us. We are always excited to see more work and help out where we can!
As a kickoff to the Lean Startup Conference this week, Pivotal hosted two tours of our San Francisco office. At the end of each tour we did a quick Q & A session. We got some great questions about how we use Lean Startup with our clients, so I’ve tried to capture them here
1. Is there a one-size-fits-all Lean Startup process that you use here at Labs?
Every client is different, and every product is different, so no. We offer several services to our clients, including helping them to identify the right project to build, helping them to validate their assumptions about a single project, and working on validation with them in-line with ongoing projects (that is, helping to look critically at their assumptions and to construct experiments that help them test those assumptions). We use the right tool for each job, and we never want to apply process where none is necessary. Less is more.
2. I imagine you have a broad base of clients (from startups all the way to big enterprises). Are there differences in the ways in which you have to interact with those clients?
Absolutely. The biggest difference is that for startup companies you get to have all the right people in the room by default. Usually the founders are right there with you, so you don’t have to worry about “pop-up” stakeholders. With complex clients we find that we have to work harder to manage stakeholders, build trust, and get people to feel understood. Finding and including everyone who needs to believe in the decisions made throughout the project can be a challenge with complex organizations.
3. Does Lean Startup apply to hardware?
We don’t build hardware projects at Pivotal Labs, but I’ve talked with a lot of people who do. The cycle time is longer (depending on the kinds of experiments you need to do), but the mindset is the same. You have to aim for low-fidelity prototyping and find creative ways to test value propositions.
4. How do you work with clients who are committed to a pre-defined path and are not allowing validation (or invalidation) to change that path?
We work really hard to get clients to focus on the value that they want to deliver to customers, but honestly sometimes it just doesn’t work out that way. Once a complex client has decided what they want to build, deviation from the path can sometimes be prohibitively complicated. This is usually for “people” reasons; at some point in the past, structures have been put in place to control the product development process. These controls were probably established for good reason, but they don’t always support delivering customer value. What they generally aim to support is completing projects on time and on-budget. It’s hard to fight against so much legacy process (and culture). In these cases, we try to get the client working as far toward Lean as they’re able to go. If there’s resistance in one direction, we move toward areas of less resistance. Ultimately it’s more important that the client understand the value of Lean Startup process than applying it perfectly to one specific project.
5. How are metrics being used for validation at Pivotal Labs?
For the most part, the validation we’re doing with our clients is at very early stages in product development, and at that point we look for direct and qualitative customer feedback. We encourage clients to think about the kinds of value that they most want to deliver their customers through their products. Once that’s clear, we can instrument for collecting quantitative data that that will prove or disprove that customers are getting what they need. We guide people toward choosing no more than three core metrics to keep track of, and to only measure if they’re willing to let the results guide their behavior. If the metrics data won’t change what you do, there’s no point in even looking at the numbers.
6. How does Lean Startup apply to “business as usual” (as opposed to a new project).
Really it’s the mind-set. When the understanding sinks in that you assume more than you know, then it’s pretty easy to start identifying those assumptions. The next step is to decide which ones are worth testing. You can’t test everything, and some assumptions just aren’t that important, so just choose the biggies. This mind-set can apply to any kind of work. We’ve applied this thinking to HR teams and marketing teams, and it only takes a little extension of the metaphors to see how it works. Your day-to-day life on a product team may be more about optimization than about creating a new product, but you can still keep these ideas in mind and experiment small before committing to big, risky builds.
We’re really excited to be the Presenting Sponsor of the Lean Startup Conference this year, and I’m excited to meet more people and carry on this conversation.
There is much about the Pivotal Process that is strikingly different from how most software is written. This talk – originally a recruiting talk given at UCB – first describes the Cloud Foundry project and then dives into the Pivotal Process: the whats and the whys behind Pair Programming, Test-Driven Development, and Agile Product Management.
Lack of diversity isn’t just a social problem, it’s also a business problem. In this video, Kane Baccigalupi talks about different types of diversity, why companies should care about it, and what companies can do to improve themselves.
In this talk Phillip Webb provides a whistle-stop introduction to Spring Boot by showing how the “Spring Doge” demo application was built. He’ll show how you can combine AngularJS, Mongo DB and WebSocket technologies using Spring as the glue to hold it all together. He’ll also demo some of the “production ready” features of Spring Boot such as metrics and monitoring.