Some text in the page

Builder sprint zero

Animoto was struggling to launch Builder, it's flagship product. The technology was amazing, but the product was not cohesive. The team was also not cohesive. Product decisons were subjective, a battle of opinions. I used a sprint zero to define an objective and actionable framework of insights and principles. This facilitated product launch and guided product development post launch.


 
 

I joined Animoto as Head of Design in February 2016. My first design responsibility: help unblock the launch of Builder. Builder was Animoto’s second generation video creation tool. It had been in development for two years. The company had tried a soft launch of the app a few months prior, but the numbers were not good. For all fo Builder’s potential, something was off.

When I audited the product, several things stuck out to me as problematic. Still, I wanted to tread lightly. Animoto called itself a startup, but it had a ten year history of success. It was a stable and profitable company. Animoto was doing something right, even if our new product grated some of my design sensibilities.

I felt I needed to observe holistically - the product, the team, the leaders, how things were being done as well as what was being done.

 

Problem

 

Here’s what I observed:

  • No critical path - Every time I opened Builder, I had a moment of uncertainty about what I should do. Every time, I had to look around the interface and think for a microsecond before taking action. I am a strong believer in defining critical path and Builder did not have one. The app was a collection of features that relied on the user to make sense of things.

  • Subjective conversations and decisions - The team had a lot of opinions. Conversations were pretty much all opinions and beliefs. Tom, the Head of Product at the time and a visionary, held strong beliefs about how Builder should be. The team aligned with his vision in principle. But, in the weeds of product design and development, there was conflict. The vision often seemed at odds with pragmatic and seemingly obvious design decisions. Which way should the team go? There was no objective grounding for figuring this out.

  • Lack of human-centered thinking - The designers were talented and user-centric product designers. But, without human-centered insights, they struggled to present design elegance which satisfied Tom’s vision.

While these appeared to be three different problems, they had one root cause. Our conversations and activities were not centered on the people who actually used our program. Without very specific human-centered understanding and insights, our product design was generic, often reactive, and subject to individual whims.

There was also a broader issue: Animoto did not know how to work with the design function. The company was smart enough to hire talented designers. And yet, these designers were not included in product strategy discussions. This meant designers were being called in after key decisions were already made. The designers felt, and rightly so, that they were doing clean-up for bad design decisions made by non-designers.

 

Solution

 

I asked leadership to let the two product designers step away from feature work for two weeks. I wanted them to team up with me on a design sprint zero. Our task: define an actionable design strategy for Builder. The designers needed an opportunity to define the big picture. I promised leadership that this up-front effort would unblock the whole team in the coming months as we ramped up to launch.

I felt we could produce a comprehensive design strategy in just two weeks because a lot of the legwork had already been done. Animoto already had a detailed product vision. They had collected user understanding from jobs-to-be-done interviews and test user feedback. And there was a lot of anecdotal knowledge stored in individuals throughout the organization. We just needed to synthesize this knowledge into simple and actionable insights and guiding principles.

The company agreed, our team did our thing, and four months later Builder launched in beta. The beta met it’s KPIs, measured over a three month period. Builder officially launched seven months after our sprint zero. Below, I tell the story of what we did in those two weeks. Most of the visuals are slides from my post-sprint presentation to the team.

 
 

Step one: Focus on a single audience

 

Builder was designed for video marketers, but they are not a homogenous group. At the time, we divided video marketers into Emma and Mary:


Emma

Works in marketing department

Young, ambitious, urban, professional, very busy

Has design resources & content

Mary

Independent marketing consultant

Middle-aged, mom, solo-preneur, “self-made”, ambitious, very active

Does not have design resources & content


Mary was a bigger customer base, but Emma was a vocal minority. Mary was non-creative, Emma was a creative professional and power user. Mary used Builder because it was the only application made for her. Emma used Builder because it was orders of magnitude faster than AfterEffects, but she still wanted AE level features.

Mary’s and Emma’s needs were often diametrically opposed. Trying to solve for both meant we were not making progress with either. We had to choose.

Emma was a tempting emerging customer. Supporting Emma meant we would see benefits such as opportunities to work with big brands. Emma was a video profesional with content and resources. The videos she produced on Animoto would make us look good. Should Emma be the primary customer?

Nope. Our data showed Mary to be the better customer to focus on. Mary was both a larger and more dedicated audience than Emma. No other tool (at the time) served Mary’s needs like Builder.

Mary was also the more engaged customer. Mary did not identify as a creative, but her career was built through ingenuity and tenacity. She was active in online communities and proactive about sharing knowledge and tools with others. She had already shown that she would evangelize Builder because the product’s growth would parallel her growth.

Animoto’s ten years of success was based on making video creation accessible to people who had never made videos, i.e. Mary. Tom’s original vision was based on serving Mary and we felt the data showed this to be the right call.

It can be hard for an organization to narrow customer focus, to deprioritize a vocal customer group. Deprioritizing Emma meant letting go of the more creative user. It meant deprioritizing power features which the internal team, ourselves power users, would love to work on.

But, after seeing the data, the team agreed that Mary should be our focus. Her needs, not our opinions, would be the framework for product conversations and decisions.

 
 

Step two: Understanding Mary’s (and our) challenges

 

We knew, from jobs-to-be-done interviews, that Mary had two challenges: poor content and lack of creativity. The root of the product vision was solving these two challenges. But the product vision only addressed the challenges in broad terms. We needed specifics.

Challenge: Poor content

Let’s say a professional videographer made videos of 100% quality - the goal of Builder was to allow the lay person to make videos of 80% quality. We felt we could get anyone, regardless of ability, resources, or effort, to 80%. That was the output goal, but what was the input? Just how far did we need to carry Mary?

Based on the data, we hypothesized that Mary’s start point was 20%, as shown in this visual:

 
 
Copy of Builder Iteration Review - 04.08.16.pptx (12).png
 

Here, input quality weighed both aesthetic quality (lighting, composition, image quality), volume of source content, and initial effort. Emma, working in a professional marketing environment, had access to other professionals as well as volumes of high quality in-house stock. Mary had very limited resources.

This visualization reminded us of why we needed to focus on a single customer. Our task was to leapfrog the user from their input level to the output level. Getting Mary from 20% to 80% was a very different journey than getting Emma from 40% to 80%.

Challenge: Bridging the creativity gap

The Builder vision was to help people produce video despite their (self-proclaimed) lack of creativity:

 
 
Copy of Builder Iteration Review - 04.08.16.pptx (2).png
 

I used the following visualization to illustrate this challenge to the team. I used and analogy of building a toy model of a person:

 
 
Copy of Builder Iteration Review - 04.08.16.pptx (3).png
 

Without any support, the user is starting from a blank slate. Builder assists the user by providing building blocks:

 
 
Copy of Builder Iteration Review - 04.08.16.pptx (4).png
 

In our visualization, blocks can be represented as the basic components of the model:

 
 
 Note: This visualization is analogous to most Builder blocks at the time, which were mainly content identifiers such as video, image or text blocks.

Note: This visualization is analogous to most Builder blocks at the time, which were mainly content identifiers such as video, image or text blocks.

 

As we see, blocks move us past a blank slate but still require a lot of the user. The user still needs to know how to assemble the blocks. If there is no end-state to guide them (and even if there is), the user has to figure out a lot.

Simply providing blocks to users did not bridge the creativity gap. We needed to get more specific about what blocks should be.

 
 

Step 3: Define actionable principles

 

The Builder vision had two high level principles:

  1. Low input, high output (“low-high” for short)

  2. Toy not tool.

These were excellent principles, but we needed to flesh them out. I believe design principles should be guides and heuristics that can be applied in day-to-day tasks and decisions. They should be specific enough to lead to definitive answers while not limiting the exploration of those answers.

Our work so far provided some concreteness to low-high: We were taking Mary from 20% to 80%. This was in contrast to Emma, who started at 40%. It was also in contrast to emerging tools from Apple and Google which essentially started at 0% by automatically creating videos from your library.

We now needed to define “toy not tool”. This would give us better design direction for blocks and Builder features in general.

Up to this time, conversations about toy vs tool were about how much control we should grant the user. I wanted to show that limitation was a secondary concern. The true value of a toy-not-tool approach is that it empowered more people to succeed by using intrinsic guidance:

 
 
Copy of Builder Iteration Review - 04.08.16.pptx (5).png
Copy of Builder Iteration Review - 04.08.16.pptx (6).png
Copy of Builder Iteration Review - 04.08.16.pptx (7).png
 

For Builder, this meant blocks should have a self-evident purpose. Mary should not have to think about why and how to use a block. If Mary is starting from a template video storyboard, she should grasp from a glance why each block is present and in a particular order. We could also build in safeguards so Mary would not misplace a block by accident. For example, if she tried to put a main title block in the middle of a video, we could guide her towards best practices.

The final insight for bridging the creativity gap was that we should, when possible, enhance user actions.

 
 
Copy of Builder Iteration Review - 04.08.16.pptx (9).png
 

We took inspiration here from Adobe Comp, a mobile tool that transforms rough gestural drawings into clean vector layouts. Draw a rough rectangle in Comp, it creates an image placeholder. Draw a line, it creates a line of “lorem ipsum”.

The key here was low-high based on anticipating user intent. Another way to state it: do less, get more. Whenever possible, we should understand user intent and user their action to point us in the right direction. What we deliver should be based on their intent, not their level of effort.

More specifically, for Builder this meant Mary shouldn’t have to think too much. When she is editing the timing, she should not have to be precise micro-second. We should handle that for her. When picking a color, she shouldn't have to think about subtle variations in hue that would work better. We should be handle those details for her while still letting her feel in control of the output.

The takeaway from all this was a counter-intuitive realization: we would not bridge Mary’s creativity gap by enabling creativity. To get Mary to 80%, we had to enable quality assurance without imposing harsh restrictions:

 
 
Copy of Builder Iteration Review - 04.08.16.pptx (10).png
 

Finally, we wrapped up our search for principles by coming back to Animoto’s incredibly successful first product, Maker. Maker’s users were consumers but like Mary. They did not identify as creative and had almost no experience with video. Yet Maker users became avid video makers and loved using the tool. Why?

Simply put, we realized users see Maker as magic. What users got out of it was so far beyond expectations that it seemed magical to them. Could this magic be replicated? By pouring over user interviews and feedback, we discovered that magic is a formula that could be replicated.

The formula for magic:

  1. Expectations

  2. Curiosity

  3. Surprise rewards exceeding expectations & comprehension

  4. Delight, wonder, joy

This was the final ingredient we needed. By understanding the formula for magic, we could define in detail our foundational principle of “low input, high output”:

Low input → High output

aka Do less → Get more

  1. Comprehend less

  2. Learn less

  3. Think less

  4. Work less

  5. Get more

  6. MAGIC!

Builder had to deliver magic! We now knew the steps to do that consistently. We had a formula we could apply when making big and small product design decisions.

 
 

Step 4: Mapping

 

The principles told us what we needed to do. We now had to figure out where in the user journey we had the best opportunities to provide magic for Mary. Animoto had not mapped the user journey before, so our little team go to it.

 
 
brian-tal.png
 

There are many ways to map a journey. I believe the best journey maps start by mapping user intent. To this, we can layer on the user’s mental and emotional journey. Then, and only then, we layer on the product to understand how it can best align with the user’s intent.

Our intent map was never digitized so I can’t share that. I can share what we learned from mapping intent.

We hypothesized that Mary has little desire to be learn to be creative. She is extremely busy and makes videos out of necessity. This lead to our core product hypothesis: Builder is an efficiency tool. Mary would choose to use Builder because it would get her to her desired outcome faster and with less effort than other available tools.

This insight provided our critical path:

 
 
Copy of Builder Iteration Review - 04.08.16.pptx (11).png
 

Mary’s aim was not making videos, it was posting videos using her or her client’s content. But the videos had to look good and feel individualized. Mary was very aware of what good social media video looked like and wanted her videos to match those standards.

Animoto’s job was not to open up a world of creative exploration for Mary or teach her how to make better videos. Our job was to take care of the creative while Mary focused on telling her story. But, she still had to feel like the end video was hers, not a something canned.

No sweat, we deliver magic. But, how? How do we make magic technically feasible? To figure that out, the design team sat down with the video engineers. We needed to understand the power and limits of our video engine. Specifically, where were? our best opportunities for gleaning intent so we could deliver magical outcomes?

We learned that we could best determine intent towards the beginning and end of Mary’s video creation journey. Towards the beginning, Mary could expose intent by choosing from certain options. Towards the end, when her video was mostly complete and being refined, the system could analyze it to identify opportunities for improvement. These improvements could be presented as holistic alternatives (vs individual settings) for Mary to choose from.

With this final insight, we were able to produce a detailed critical path experience map for the product:

 
 

Click to expand

 

We finished our sprint zero by presenting this experience map to the team. This map guided product development through beta launch, full launch, and afterwards.

 

Outcomes

 

Broadly speaking, the outcome was that the team was unblocked to make objective product design decisions, big and small. The beta was completed, performed well, and the product launched to the general public. Builder has a loyal user base which is growing steadily.

The online video creation space is expanding at 40% year-over-year. Animoto’s Builder is at the forefront in that space. Almost two years after launch, it is still the most flexible yet simple web-based video creation tool available.

We made a good call by banking on Mary’s enthusiasm and willingness to evangelize. Builder has several strong Facebook communities where users help each other, interact with Animoto team members, and help the company innovate.

We were not able to implement all the opportunities in the critical path map before launch. But the Builder critical path proved to be valid and Animoto is working to act on more of the opportunities we identified.

Several of the product principles are now central to Builder's evolution. The principle of "do less, get more" is central to the current product vision. "Be magical" is one of the company's core design principles

A specific outcome from the sprint-zero was a new push for simplicity. Before the sprint, product development had been about loading on new features. This usually meant adding complexity. With the new principles, we looked for ways to simplify the experience based on Mary’s intent. This led to a “quick win” improvement to the block UI.

We considered the differing intents between when Mary looked at the storyboard as a whole versus when she focused on a single block.

When Mary looked at the whole storyboard, we hypothesized that she wanted to “read” the video - get a general sense of the overall content and flow. To facilitate this, we simplified the block presentation to only what was crucial: content, block type, and duration:

 
 
 Note: this is the current UI, not the UI at launch. The block design is the same as at launch. Some other areas are slightly different.

Note: this is the current UI, not the UI at launch. The block design is the same as at launch. Some other areas are slightly different.

 

When Mary moved her cursor over a block, it seemed reasonable to assume her intent to focus on that block. We respond to that intent by showing a video preview of that block plus key input and edit options:

 
 
 

Due to a technical limitation full video previews took some seconds to minutes to render. But, block level video previews were instantaneous. Our approach allowed Mary to get an instant preview of the whole video by moving her cursor over the blocks.

If Mary wanted to update some block detail such as the text, she could do so right from the storyboard by clicking on the “T” icon:

 
 
 

This meant Mary could traverse from a broad view of her whole video to detailed edits with just a single hover and single click. She need not leave the storyboard view and expand a block every time she needs to make edits. We thought this would help Mary to quickly set up a rough draft of her video from the storyboard view, then expand each block when she was ready to fine tune.

 

Always more to learn

 

Product launches are intense, exciting, and scary all at once. We were making bets based on available knowledge and plenty of assumptions.

We saw several of those bets pan out. User feedback affirmed that Builder really is an efficiency tool for Mary. Users loved how quickly they could produce and post content. The cleaner storyboard view was also well received. We saw repeatedly that new users were able to intuit the purpose of the blocks and how to work with them.

Of course, some of our assumptions did not match actual user behavior. Post launch, we learned that Mary usually didn’t have the full video planned when she started a project. She worked incrementally. She zoomed into the first block, figured it out, then moved onto the next block and so on. The storyboard level controls were not as useful as we expected during her first pass of video creation.

However, after Mary previewed the first draft of her video, the storyboard level controls were very useful for quick edits and fixes. For this reason, they are still a part of the product.

A personal learning for me: be more concrete when sharing ideas! Designers tend to like abstract thought. The designers on my team were happy for me to provide a seed, the human model analogy, to catalyze their exploration. I hoped that would also be true for the product managers and engineers, but it wasn't so. It's not that these non-designers were not creative. They just needed a more concrete starting point for exploration.

I worked on being more concrete during my time at Animoto and it paid off. Towards the end of my tenure, I was leading regular sketching sessions with engineers. I was consistently amazed by their creative input when given a resonant starting point. More on that coming soon in another case study :) 

 

 
 

Thank you for reading! Please reach out if I can clarify or elaborate on anything presented in this case study.

 

Designing Animoto's product teams for 2018

 

Team design is product design. When Animoto was facing challenges with continuous delivery, I suggested our team design was a root cause. I proposed a team structure which accounted for two factors for agile product teams: iteration cadence and knowledge siloing.


 
 

Reflecting on 2017, the VP of Product at Animoto knew we had a problem. The company struggled with continuous delivery.

The incredibly powerful Animoto video engine had one major drawback: making changes or updates was effort-intensive and slow. This set off a chain reaction of issues. We did not ship video features as often as we wanted. Aware of the commitment involved, we spent a lot of time and energy debating which video feature to work on. We broke our core principle: ship, learn, and iterate.

 

Problem

 

As I observed these issues myself over the year, I felt the underlying problem was team design.

Animoto was dedicated to fully autonomous product teams. The product team setup was:

    Video team - Responsible for everything from new video features (effort intensive and slow) to new video templates (fast, sensitive to trends) to UX for video features (medium paced).

    UX team - All UX outside of the video controls.

    Mobile team - All things mobile but reliant on the video team for video features.

    There were several issues with this setup.

    Unmet expectations and internal conflict - Putting the template creators on the same team as the people making video features created internal conflict on the video team. The template creators had a quickly growing backlog of video feature requests which the developers could not keep up with. Templates were the core Animoto product. But we were seeing slow release and little innovation with templates.

    Unclear scope of responsibility - Because multiple teams touched UX, none of the teams were truly autonomous to release UX updates.

    Teams were not free to learn and improve based on learnings - Because teams did not have clear long-term missions, there was little cumulative learning. Each project felt like starting over. Also, teams could not act on new learnings for fear of diverging from what other teams were doing. Related, teams had to seek broad input before moving forward to make sure they were not ignorant of new learnings.

    The led to friction between product managers, engineers, and designers. The design team, who were my responsibility, felt they were not being setup to deliver their best work. The problems they were asked to solve were too narrow in scope. They were given the opportunity to account for the broader context within which those problems existed. 

    Of course, to non-designers, this sounded like the design team wanted to scope-creep on every project.

     

    Solution

     

    Animoto's product team structure had not considered two key requirements for truly autonomous teams:

    1. Teams must be free to run at their natural iteration cadence
    2. Knowledge siloing must be a non-issue

    Different product layers have different natural iteration cadences. A truly autonomous product team must be built around a single iteration cadence and free to run at that cadence. Otherwise, the team will struggle with internal conflicts.

    Knowledge siloing is a fact of life for any product org. If you have autonomous agile product teams, knowledge siloing is unavoidable. The trick is to make it a non-issue. Setup the overall system such that knowledge siloing on a team does not negatively impact other teams. Build in swarming events when multi-team input and action is needed.

    Another facet of knowledge siloing is context for designers and others. Progress is unacceptably slow if designers have to rebuild context with every project. In contrast, if projects align to a longer-term mission then context carries forward. Design gets faster and more effective with each project.

    In other words, the product we build is a direct result of the way we design our teams.

     
     

    Putting it into action

     

    I shared my view with Stevie, the VP of Product, that team design is top level product design. Team design is applied strategy: it is how Stevie connects product vision to daily tactics.

    This resonated with Stevie and he wanted to explore how our teams could be structured. Two product managers, a lead engineer, and myself were given two days to submit proposals. My proposal is below.

    It was interesting to discover that the engineering lead's proposal shared a viewpoint very similar to mine. The final team structure for 2018 was a combination of his and my proposals.

     
    whiteboard-team-structure-yellow.jpg

    Progressive disclosure for behavior adoption

     

    On-boarding is an afterthought for many products. Games teach us that the best design is built around on-boarding by considering how users will adopt and grow with a application.


     
     

    What does product on-boarding mean to you? For many product teams, product on-boarding means Intercom messages explaining the latest feature.

    I am not against Intercom messaging, but product design should not be reliant on it. On-boarding should not be an afterthought. A well designed product integrates on-boarding into it's core strategy.

    I wrote the following piece for product managers and designers at Animoto. It explains how to consider on-boarding a foundation for product design.

     
    LongjiTerraces-yellow.jpg