Explore Anthroware's collaborative approach to digital product development, focusing on vocabulary, clear roles, critical assumptions, and learning objectives.

“Do you understand the words coming out of my mouth?”

At Anthroware, one of the best things about our work is the range of different people we get to know. We work with many types of clients: Entrepreneurs, both first-timers and veterans; representatives of huge organizations; high-end consulting groups. And they come from every industry you can think of: Fin-tech, healthcare, education, real estate, even craft beer!

Because our clients bring such a broad range of knowledge and experience to the table, the beginning of every new partnership involves a lot of learning. We need to figure out how to collaborate well, agree on a process for getting work done, and establish a common vocabulary. To take a concept from the powerful communication guide, “Crucial Conversations” we must work to create a shared pool of meaning – a set of concepts we all understand in the same way.

Within our team, we already have our own shared vocabulary. Many of our conversations might be incomprehensible to people who don’t work in technology, and in some instances, even to people outside our company:

• “The link for requirements gathering is live in Sharepoint and I Slacked it to our biz dev channel.”
• “Did you log the time from that card?"
• “Are we ‘triangles’ on this?”
• “The demo was moved from 10 to 9, and the retro will follow. If you can’t make it in, join the screen share .”
• “Are we showing wireframes, or mockups?”
• “I need permissions to deploy.”
• “Are we using an API or an SDK?”
• “No, we’re not testing ‘matching and liking’ this time. We’re doing a card sort to help establish taxonomy, and then testing for basic functionality in context.”

So we learn together

While we’re busy learning the language our new client uses every day, so that we better understand their software needs – “That feature needs to be HIPAA-compliant.” “We need to integrate DotLoop.” “What are the business rules for sending “critical” messages?” – they are learning similar things about us and our process. What’s involved in digital product development? What is the best meeting cadence for this project? Who’s on the project team… and what exactly do they do again?

For example - I’m a Product Owner (which you may not have heard of), not a Project Manager (which you probably have heard of). And when you work with us, you might be working with a Software Engineer (sounds fancy), not a Web Developer (which you may have assumed). You’ll learn about our scrums (quick check-in meetings) and our demos (presentations of completed work). And we’ll do our best to learn as much about your business as you know about it.

You probably came to us for Kendra

Our team’s success depends on three essential components: Opportunity, Usability, and Code. In this post, we’re going to focus on the first two.

(Speaking of jobs you didn’t know existed), as our Lead UX Designer, Kendra Sarvadi focuses on the Usability component of our process. As the person responsible for understanding a product’s users, she thinks a lot about the Anthro in Anthroware. She does as much research as we’ll let her on the people we build products for, trying to understand their needs, behaviors, perspectives, and context, to help inform product design. She also designs, conducts, and synthesizes results of the tests we perform on products. She uses a set of Learning Objectives to help decide what to test, to produce meaningful results that can inform design decisions.

You’ll hear a different phrase from me and Jon

Jon Jones (our President and CEO) and I work on the Opportunity aspect of the business. When we meet and talk about how a new digital technology can impact your business, we take a somewhat fiduciary role. We want to make sure you’re making the smartest possible business decisions. If you like spreadsheets, boy are you in for a fun time when we get together! When we meet with you to explore Opportunity, we’ll talk a lot about Critical Assumptions.

Building a shared pool of meaning

It can take some effort to make sure everyone involved in a project has a shared understanding of terminology. Depending on the complexity and requirements of a project, it can help to create a glossary. However we achieve it, it’s clearly important to understand the language we use, if we want to communicate clearly.

"Critical Assumptions" and “Learning Objectives” keep coming up for us, so let’s break those down. What are they? How are they different?

Critical Assumptions

Let’s say you have an idea for an app that helps people find places they can go with their dogs; like a Yelp for dogs (full disclosure: I built this very app before joining Anthroware). People can go on the app, find their location, and see every dog-friendly venue near them: Parks, hotels, beaches, restaurants, etc., and for each place they can see ratings, reviews, photos, and so on.

Critical Assumptions are the factors that determine the success of your product. If any of these fail, your product is in serious jeopardy. These are the things we must get right. We identify these Critical Assumptions when we explore the Opportunity aspect of your product.

If you came to us to build this app, in our very first meeting we’d have the following critical assumptions laid out on a whiteboard:

Critical Assumption #1: People need a way to find places where dogs are allowed.
Critical Assumption #2: You have to find a way to populate enough locations in the app that, when people log in, there’s enough content to keep them coming back (or, just enough to be “good enough”).
Critical Assumption #3: The GPS locating system works reliably.
Critical Assumption #4: The locations are accurate and up-to-date.

Learning Objectives

As Critical Assumptions help identify “Opportunity”, “Learning Objectives” involve Usability. We have nine types of tests we can conduct with users, and each one tests a different aspect of the product. When we design these tests, part of our job is to figure out what we are trying to learn. Learning Objectives are how we determine what we need to know, and then what questions we should ask to find out.

Keeping with the dog-app example:

Learning Objective #1: Can people find the most important features? For example, can they find the map, and set their location?
Learning Objective #2: Does our interface allow people to easily identify dog-friendly venues near them?
Learning Objective #3: Can people easily find additional information about each venue? Are we providing the most valuable information?

The questions we ask and the methods we use to achieve each Learning Objective depend on the goal. Sometimes it makes sense to survey people; for example, if we wanted to learn whether they might be interested in our product, we might first want to know if they have a dog. If we want to know whether something is easy to find in the app, we could observe how long it takes for them to find it, and ask them to describe what they are thinking while they look. As is often the case, the best tool for the job depends on the job.

Critical Assumptions and Learning Objectives

At Anthroware, both Critical Assumptions and Learning Objectives are important terms do define clearly, because they describe such fundamental parts of what we do.

Critical Assumptions are the success-determining factors for your product; you absolutely must get these right, because they help you set goals and expectations based on the value of your product in the market.

Learning Objectives are usability-determining factors. You must get these right, too, because they inform the ultimate design of the product, and can affect whether people use it at all.

Critical Assumptions = Opportunity.
Learning Objectives = Usability.

Happy designing, and happy testing!