Author: Jessica Wilson

Is There a Market For Your Product?

If you have ever come up with a ground-breaking idea for a new product, you are probably familiar with the feeling of FOMR. Unlike the popular “FOMO,”  FOMR is the Fear Of Market Research. It is the avoidance of conducting research to validate (or invalidate) that not only does a need exist for your idea, but also that the barriers to entry are not insurmountable. Taking such an approach when building out your product strategy means you are walking into the market blindfolded, which will certainly result in some rather unfortunate consequences that could otherwise have been avoided.



Sometimes it’s nice to know what’s behind a door before you open it.

The Fear

Many tend to avoid this step simply because they are afraid of discovering that there isn’t as much demand for their product as they originally thought, or that the market is already saturated with similar solutions.

Additionally, the potential cost of conducting research (in both time and money) can seem unappetizing as well. if you are already convinced the product will be a success it can be hard to justify burning limited resources to tell yourself what you already know.

Despite the uncertainty, foregoing this crucial step is never a good idea. It’s easy to tell yourself that everything will probably work out just fine, or that you will simply learn and adjust as you go, but it is for this very reason that the road to market domination is littered with the carcasses of the ill-informed and unprepared


Sasha (Sonequa Martin-Green), Bob Stookey (Larry Gilliard Jr.) and Maggie Greene (Lauren Cohan) - The Walking Dead _ Season 4, Episode 10 - Photo Credit: Gene Page/AMC

Watch your step…

The Solution

One method to getting past this fear is to reframe it in your mind as a way to preemptively solve or avoid future problems. When done properly, market research will help you identify and understand your target users, differentiate your offering, fine-tune your original concept, and increase your product’s chances of user adoption.

Industry Research

What are the revenues for your category in your local market, regionally and nationally? One good resource for this is ibisWorld. If there’s little money to go around in the industry you are serving, you’d better make sure you can capture the majority of it.

Identify trends in your chosen industry. Many larger companies often demonstrate their expertise and thought leadership by releasing industry outlooks or annual reports and white papers. These can be a great resource for understanding where your field is heading and what pains are being experienced across the board.

Determine if the market is new and growing or static and mature. Has your industry been around forever and become a staple in people’s lives, like shoes or haircuts? Or is it emerging and exciting, like augmented reality or connected devices? Can you compete in a mature market saturated with competition, or stay at the cutting edge in a new market that could evolve overnight?

User and Customer Research

Determine who the users of your product are. Hint: the answer isn’t “everybody.” Your users and your customers may not actually be the same people and depending on your product, you may even have multiple types of users. You’ll need to understand them all if you want your product to succeed. Identify their age groups, ethnicity, geographic location, job titles, income levels, etc.

Conduct User Testing. Get out there and interview people who fit your user personas. Understand their pain points, what their goals they want to achieve, how do they want to interact with your product? A great way to get this information quickly and inexpensively is with the use of paper prototypes or other low-fidelity mockups of your concept that your test subjects can interact with prior to building a (more expensive) finished product.

Once you have determined who your users are, be sure you can answer the following questions:

Are there enough people who fit my criteria?

Will my target really benefit from my product/service? Will they see a need for it?

Do I understand what drives my target to make decisions?

Can they afford my product/service?

Can I reach them with my message? Are they easily accessible?

Competitive Research

Know who your competition is. Hint: the answer isn’t “no one.” Just because you may be the only one doing exactly what you are doing, does not mean you don’t have competitors. Be thorough. Cranking out a google search on a few keywords and calling it a day is not enough. Dive into message boards, articles, and blogs (which tend to quote industry leaders that may be competing with you). Peruse top ten or top 100 lists of the best rated or reviewed providers in your industry.

Once you have built a comprehensive list of your competition, check out their websites to understand their offerings and differentiators. What makes their product special? How long have they been offering these products?

Who are their customers? Where and how are they marketing? What do their customers love/hate about them and their product? Check out their support forums to see if there is a feature their customers have been begging for that they have not developed yet. Simply put: Know. Thine. Enemy.



It’s this guy. Definitely this guy

The Benefits

The moral of the story is: don’t let FOMR get in the way of building a great product. Once you’ve done your homework, you’ll be able to make smart strategic decisions around the direction and development of your product. You may even discover that your original concept won’t do the trick, but with some tweaks and repositioning, it could solve another need you weren’t aware of. Launching a new product (or business is like wandering your way through hostile territory. There will be lots of hazards and pitfalls hiding around every corner, but if you’ve equipped yourself with the knowledge required to make the right decisions, you stand a much greater chance of making it through.



I’m sure you’ll be fine!


Developing an amazing technology product of your own? Take our 1-Minute self-assessment to make sure you’re project is on-track for a successful launch!

Building Teams of T-Shaped people

Are your teams made up of T-shaped or I-shaped people? If that question causes you to cock an eyebrow, let’s ask it another way: If one person calls in sick tomorrow, does their job still get done, or does the office collapse into a state of violent anarchy? (Note: Other options may lie somewhere in the middle…)



“Hey guys, are we thinking this through?”

“Damn it man, there’s no time! Steve is out sick and no one else knows Javascript!“


A T-Shaped person is an individual who has deep knowledge of a specialized skill set in addition to a range of acquired tangential, related skills. They are also known as generalizing-specialists or “Renaissance” workers. In comparison with the “T” shaped individual, “I” shaped individuals focus mainly on their own specialized skill-sets, often view the workplace as a competitive environment, and tend to work within disciplinary silos. When a team is comprised of highly specialized I-shaped people, there is little room for any kind of structural change. For example, what would happen if Baracus suddenly quit the A-Team? Who else could pull off that look? Face? Murdock?


THE A-TEAM -- Pictured: Mr. T as Sgt. Bosco "B.A." Baracus -- Photo by: Herb Ball/NBCU Photo Bank

“Girl, please.”

Benefits of Teams of T-Shaped People

A team of T-shaped people (aka. cross-functional team) complements one another with both their specialized knowledge and overlapping skills to form a high performing unit.

Cross-functional teams experience less internal bottlenecks and contention for one person’s time.

T-shaped people can view situations from different perspectives, bringing not only their specialized knowledge to the table, but wide-ranging experience in other areas as well.

T-shaped people help fill skills gaps and take on new skill sets quickly. This then leads to higher overall team productivity and greater flexibility.

Such teams are not limited by a single point of failure (SPOF). Should Steve leave the team, Amy has sufficient knowledge to keep the project going.

Building Cross-functional Teams

Step 1: Understand

Start by mapping all of the disciplines or functional areas necessary for your team to complete projects as columns on a graph.  Then, work with each team member to assess their capabilities or expertise from one through ten in rows going vertically. Be sure to understand ahead of time what it means to be a 1 or a 10 in each area to avoid arbitrarily assigning numbers. Once complete, you will have a big picture view of your team’s capabilities as a whole.

Screen Shot 2016-08-25 at 2.14.34 PM

Originally posted on Scrumtalks

Step 2: Plan

At this point, you can begin discussing strategies to help fill in the empty spaces. Be sure to create a clear process for closing skill gaps, enlisting the help of designated “experts” in specific fields to design collaboration procedures. When done in a positive manner, from a position of support (not judgment or blame), this can drive some great discussion and re-energize employees.  With a solid plan, time, and consistent effort, teams will eventually grow into cross-functional units.


c08819dc22526597e1e9673e55fd3716“I love it when a plan comes together…”

“Ugh, God George, we know.


Step 3: Implement

With the skill gaps identified, and strategies in place to fill those gaps, it is now time to work with management, team leads, and your experts to execute.

Provide ongoing training for all employees on topics relevant to your business’ core functions, to standardize the horizontal portion of the “T”. As skilled as Dwight might be in competitive helicopter aerobatics, unless your organization plans on expanding into the airshow market, it doesn’t make sense to invest time into turning the rest of the team into amateur stunt pilots. It does however, make sense to have Dwight pair with other team members on Ruby so that the next time he ends up in the hospital due to a helicopter-related accident, his co-workers are able to carry on his portion of the project without him.



Rest in Peace, Dwight

Make sure you have a solid workflow in place. Increasing employees’ skill levels won’t do much to boost performance if there are inherent problems in the processes they use to work together. Creating a value stream and identifying areas of consistent churn to streamline will help mitigate frustration and can even help uncover additional skill gaps that need closing.

Set clear expectations. This may seem obvious, but simply saying to your teams “improve yourselves!” will not yield positive results. You’ll have to clearly define what success looks like on an individual level, a team level, department level, etc.

Work with employees on an ongoing basis to understand their core competencies, evolving skill sets, and emerging interests. Things change. Staying informed means you can adapt the strategy as needed.

Create focused learning activities around bottlenecks.

Build cross-team communities of practice around technical specialties, domain knowledge areas, or any other areas of interest.        

Work with team leaders to establish an environment that encourages continual learning activities such as pairing, job shadowing, lunch-n-learns, book clubs, and open discussions. Empower employees to be honest with their T-skills and discover solutions for the areas in which they are not experts. Build continual improvement into the culture by encouraging collaboration and support from all levels. The goal is to make employees feel comfortable asking for help and running experiments so that they can grow their expertise.

Finally, help create consistent boundaries for workloads and job functions. Being a T-shaped employee does not mean become a master in everything and employees with broad skills should not be driving initiatives outside of their core function, especially when there is an expert on the team. Just because accounting expert, Dirk, cross-trained Lawrence on processing payroll, does not make Lawrence the new accountant.



Deal with it, Lawrence.


By following the above guidelines you can optimize your teams, leveraging their strengths and building their individual skill portfolios in the process. However, just because you may have have all capabilities necessary to do the work, it does not necessarily mean you have a high-performing team. To achieve high-performance, teams will need to have the right communication and collaboration processes in place. This area is often the most challenging for teams, but it is critical for sustainable success. Want to know if your teams are maximizing their performance potential? Take our 1-Minute Agility Self Assessment to find out!

Building The Boat of Things

Boat of things

With the variety of different IoT-related work we do (including the oft-blogged-about CWRU course), it only made sense for us to have an “IoT sandbox” to experiment and play with. It was one of our hack days that provided us with an opportunity to bring such an idea to life.

Building a sandbox gives us an opportunity to experiment with new IoT devices and software, while giving LeanDoggers a breakable toy to work with during hack days …and for some nerdy fun. It also allows us to start collecting sensor data for research and exploration.

First Iteration

The first iteration of this idea consisted of two parts — one team would build an Alexa Skill for the Amazon Echo to ask as an interface to other devices on the Boat-of-Things network, while the second team would build the infrastructure, set up the MQTT broker, and start connecting other devices.

By the end of the first iteration, we had established our user interfaces into the Boat of Things — a Slackbot called Otis, which acts as a sort of command-line interface, and an Alexa Skill, allowing us to say “Alexa! Ask Otis to <verb>”.

We also built our first actual integration — a long-standing issue in the LeanDog Studio is music. Since the inception of LeanDog Studio, we’ve used a Mac Mini attached to speakers running a browser with Pandora. We would individually VNC into the server to change stations, with a mutual understanding that any station played should be kept on for at least three songs to prevent music anarchy.

Okay, so we didn’t solve music anarchy — what we created is a Google Chrome plugin that scrapes the website and publishes the stations and current playing song. It subscribes to a control topic that allows playback control and changing stations.

By the end of all this, we could say “Alexa! Ask Otis what’s playing” or use Slack:


Other Integrations

The number of integrations we’ve built since then has exploded. Here are some of them:

A couple years back GE created this module for makers called Green Bean which can connect to the diagnostics port of some of their appliances. We just happened to have compatible appliances on the boat, so we ordered one and hooked it up to our fridge and a Raspberry Pi.

The status of the fridge is now published over MQTT, which allows us to create some alarms:


And do some fun useless things:



Weather Station

In the quest to attach all the things, we found that our weather station upstairs had a USB port! We attached yet another Raspberry Pi (we’ve got a lot of Raspberry Pis) and publish the data every few seconds. We also used the opportunity to script an integration with Wunderground — our station handle is KOHCLEVE65. Now we can ask Otis for the weather:


CI Screen + Radiator

We have a couple radiators running on mounted TVs around LeanDog Studio, including a CI board and individual project radiators. All of those subscribe to a marquee topic, which allows us to display images and animated gifs for a set amount of time. For instance, when someone finishes off the coffee and doesn’t brew a new pot:

Screen Shot 2016-08-04 at 12.45.35 PM

Works In Progress

Motion Sensor

In the future hope that we’ll be able to play some music when the boat starts rocking, we started logging motion events on the boat. To do this, we employed the help of an ESP8266 module and a 9DOF sensor.

motionThis is a really cool module that uses several sensors including accelerometer, gyroscope, and magnetometer and outputs simple euler angles so we know our position and orientation in 3D space. Right now we’re just collecting data in Amazon DynamoDB — soon, we hope to trigger some interactions when the boat starts moving — maybe a dramamine dispenser?

Coffee Pot

Our own Steve Jackson is working on a connected coffee scale to let us know how much coffee is left in our carafes and when it’s time to brew a new pot. The proof-of-concept has been completed and soon we’ll be building two of them and installing them in the kitchen.


That’s it. Let’s polka!

Finally, every Friday morning after standup, we allocate a little time to cleaning up the boat. For historical reasons that no one quite remembers, we do this to polka music. Thanks to an integration with the Amazon Dash button, announcing cleanup is simpler than ever:


Developing an amazing technology product of your own? Take our 1-Minute self-assessment to make sure you’re project is on-track for a successful launch!  Or, reach out to us at! We’d love to hear all about it!

Is Your Office Space Hindering Your Employees?

If you work in a traditional office, you’ve probably experienced the frustration of wandering through a maze of cubicles like a lab mouse in search of cheese, trying to find the one co-worker who can answer your question. It only gets more irritating when you discover that said co-worker has abandoned their own post in search of someone else to answer their question. With a heavy sigh, you trudge back to your seat, punch out your query in an email, and watch time tick away as you wait for a reply.


The Age of the Open Workspace

Despite our progression towards an increasingly virtual world, face-to-face communication is still extremely valuable. Relying predominantly on emails for collaboration results in misunderstandings and really, REALLY slow feedback loops.

In open workspaces, teams use open seating to facilitate communication, shorten feedback time, and speed up ideation. It is often the hardest practice to implement when making internal process improvements, but the resulting transparency and increased communication make it incredibly impactful.


Okay, bad example.

Assess Your Space

If you are considering transitioning to a more open environment, you’ll want to put some thought into what isn’t working now and what you anticipate a more open office space would help your team achieve. The following are some questions to help determine how your current workspace configuration affects collaboration and to get your juices flowing around how to turn your space into a productivity tool.



To get started, ask yourself:

  • How quickly can you currently get questions answered or receive feedback on requests from your peers? How about your management? Senior leadership?
  • How many emails back and forth does it take to resolve an easy issue? How about a complex one?
  • How often do you find yourself picking up the phone or typing out an email to speak to someone down the hall or across the room?
  • Do most of the steps on your Fitbit come from wandering around the office looking for team members?
  • How many meetings are scheduled simply so you can get all the right people in a room together to work on a single issue?
  • Do you see pictures of offices like Google or QuickenLoans and think “God, I wish I could work in a place like that?”
  • Do your teams keep stashes of vitamin D in their desk drawers because the only time they are exposed to natural light is during their drive to work?

Open Space Guidelines

Depending on your answers to the above, you may be wondering what a more collaborative, optimized environment would look like. Below are some guidelines to creating a space that breaks down the barriers to communication and teamwork. Note: These are generally considered good practices, but they are not the “rules.” The team (not the boss or HR) should be allowed to work together to create an environment that best supports their needs and goals.




  • There are no assigned seats or other personal spaces (ie. cubicles)
  • Breakout rooms are available for meetings, privacy, or periods of quiet-time, but should not to be turned into personal offices.
  • White boards, cork boards or flip charts are used to provide a dynamic workspace for collaboration.
  • Team members use open seating to facilitate pairing on tasks and projects
  • Leadership sits in the open space with the team (no ivory towers)
  • Locate the team space in a highly visible area, be proud to showcase the space to visitors
  • Team members have a designated area to store personal belongings – this prevents “claiming” of a seat or area
  • Furniture is movable without permission and the team has ability to reshape the space as needed
  • Allow picture skins or stickers on laptops (family, dogs, sports, etc)
  • Allow teams to be creative and introduce fun into the workspace

Team Norms

  • Some noise indicates collaboration and communication, silence is troubling
    • The Parent’s Ear Rule: bad sounds are complete silence or kicking & screaming
  • “Hey Team” cooperation when roadblocks are discovered – Everyone swarms to help out
  • Teams sit side-by-side and/or facing each other, not with backs to one another
  • Requires that facilities, HR, and leadership understand the goals, and are engaged with the team(s)
  • All rules deserve team discussion

A Note On Introverts and Open Spaces

One of the biggest misconceptions about open workspaces is that they do not accommodate the preferences of introverted team members. The fact is everyone, even extroverts, sometimes need to work independently and in quiet so that they can focus. For many, the idea of working in an open environment with lots of “chatter” can be a rather unpleasant concept. The good news is that properly configured open workspaces, combined with the right team norms, can actually support the needs of introverts even more than traditional offices currently do.


“Go on…”

First, break-out rooms or designated quiet areas allow team members to retreat to a private place to focus on a particular task without disruption, then return to the group for collaboration when they are ready.  Second, having no assigned seating means that people are free to move away from distracting activities or noise rather than be forced to deal with it all day. Finally, the freedom to choose where one works conveys a stronger sense of empowerment and trust from company leadership. It’s as if you are saying to your employees, “I see you as adults, not schoolchildren. This is your space and I trust that you know best how to get things done.”

How It All Fits

While the goal of creating a more productive, collaborative environment is certainly worth pursuing, it should be noted that simply taking kicking down your cubicle walls while declaring “open workspace!!” will not do the trick.  It will, however, get you some frightened looks from your employees and a rather stern talking-to from HR.


Pictured: Not the answer.

The implementation of an open workspace is not a solution in itself. Rather, it is a critical step in a larger movement towards a more optimized operation. Some would even argue that the switch to an open workspace is really just a byproduct of adopting more collaborative, transparent practices – that it naturally emerges as processes become more streamlined. It is therefore critical to define what your goals are for your open workspace and to consider what operational changes will need to take place in order to ensure the transition is successful.

If you are considering optimizing your office space and processes, a good place to start is by taking a quick assessment of your current situation with this one-minute quiz. The results will give you a good idea of how adaptable your organization is today and provide steps you can take to make incremental improvements.


Agile…and BEYOND!!

LeanDog Agile experts, Matt Barcomb, Mike Kvintus, and Jeff Morgan, are at Agile and Beyond today and tomorrow. Take a peek at some of the knowledge they will be dropping while they are there:

Screen Shot 2016-05-02 at 4.58.17 PM


Matt (@mattbarcomb) is a product development specialist with a penchant for organization design. He works with companies to turn software development into a core competency by integrating product development activities with business practices. Matt takes a pragmatic, systems approach to improvement, working with stakeholders throughout medium and large organizations. He has experience working with product management and software delivery teams as well as executive leadership teams, sales, services, and operations in a variety of industries. Matt enjoys challenging mental models, simplifying the seemingly complex, and uncovering the “why” behind the what. He shares his experiences, questions and ideas at

Thursday, May 5 @ 10AM Value-focused prioritization & decision making

Does prioritizing your development portfolio seem unclear or mired in politics? Ever feel like the decisions for what gets worked on when are somewhere between arbitrary and emotional? Ever get tired of providing cost estimates for work of uncertain value? If you answered yes to any of the above questions, this session is for you! Matt Barcomb will open with introductory concepts about shifting from a cost focus to a value focus for development work. Next, providing business value for user stories will be debunked. Then, a collaborative framework for prioritization, Benefit Mapping, will be discussed. Finally, Matt will end with ways to simplify the cost evaluation of work and risk.

Friday, May 6 @ 10AM Using Flow-based Road Mapping & Options

If you’d like an alternative to typical, quarter-by-quarter, schedule oriented road mapping (and all the associated waste) then this session is for you. Matt Barcomb will introduce a Cadenced Flow approach to flow-based road mapping. He will first cover how to layout and execute a road map based on models that better fit software planning as well as how to transform your existing plans. Next, using options thinking to frame work will be explored and how to use starting and stopping triggers for options, reducing the need of blind budgeting or project practices. Finally, Matt will wrap up by touching on a few key metrics that will let you monitor and evaluate your new road map.

Screen Shot 2016-05-02 at 5.00.09 PMCheezy

Cheezy is an international speaker and keynote presenter in different Agile conferences. He has spoken 6 times at the Agile 20XX conferences as well as other ones like Agile development East and West, Mile High Agile, Agile and Beyond, Path to Agility, etc.

Friday, May 6 • 3:00pm – 4:40pm Tested!

You’ve heard that quality belongs to everybody on an Agile team. You’ve heard that testers and developers should “collaborate” in order to drive quality higher. You’ve heard that automated tests help a team continuously validate the quality. It’s time to stop thinking about it! It’s time to stop talking about it! It’s time to make it happen! Watch Ardi and Cheezy do this in front of your eyes. They will build a web application driven by acceptance and unit tests.You will see how a Product Owner, Tester and Developer will create executable User stories, develop the code to validate these stories and refactor along the way. At the end, you will get a taste of what a Continuous Delivery pipeline looks like. Prepare to collect your jaws from the floor!
Screen Shot 2016-05-02 at 4.58.39 PM


Friday, May 6 • 10:00am – 10:45am Worthless Story Card Estimates

How much of your time is wasted estimating story cards? We’ll explore some alternatives to estimating story cards and review real-world comparisons of tracking work using story points vs. counting story cards. Not sure when story card estimates are needed? We’ll discuss that too. All discussions will be based on real-world examples and comparisons of alternatives for several projects. We’ll also discuss #NoEstimates and how it fits in. You’ll leave with an understanding of ways to plan/track agile projects and the tradeoffs involved with alternatives to story card estimates.

Taking Cleveland Tech To New Heights

Whenever you meet a LeanDogger, one thing is always immediately evident: we HEART tech. Like, a lot. We love it so much that we are obsessed with growing and nurturing the tech environment in Northeast Ohio. It’s why we hold five tech meetups a month aboard our floating office, regularly speak at industry conferences, teach a college course on connected devices, and even bring in high-school students for shadowing opportunities. It’s also why we decided to invest in Tech Elevator, an innovative coding bootcamp that prepares novices for careers in the field of software development.


This 14 week Cleveland-based bootcamp helps students seeking to make a career switch rapidly develop coding abilities, while fully supporting their career goals through Tech Elevator’s hiring network and Pathway Program. As stated on their website, the program gives students “an understanding of the foundational computer science concepts and theory necessary for a professional software developer, with special emphasis on practical application, techniques, and tools.“

The founders are so confident in their training, the program comes with a money-back guarantee. If any student graduates from either the Java or .NET program and does not receive a job offer in a software development related role within 120 days, Tech Elevator will actually refund their tuition.

As Anthony Hughes, Tech Elevator Founder and CEO, puts it: “You’re not just “learning to code”. You’re entering the next chapter of your career and investing in your future. And we’re invested right along with you. ”

“We’re big believers in this business model and the team at Tech Elevator,” says Jon Stahl, President of LeanDog. “We work with some of the largest dev shops in the country and every day we witness the need for more quality developers to fill the growing IT needs of today’s business. Tech Elevator’s model is brilliant in its simplicity: find smart people who are hungry for great careers, and train them with the tech skills that companies are willing to pay for.”

Just like LeanDog, Tech Elevator is committed to sharing best practices in the craft and growing the software developer community in Northeast Ohio. To further those efforts, LeanDog and Tech Elevator will work together to help novice programmers and career changers learn more about the growing field through meetups, mentoring, training, and workshops, as well as collaborate on learning tracks that go beyond coding, to explore Lean and Agile delivery practices.

To get in on some of these upcoming events, follow @leandog and @Tech_Elevator on Twitter. You can aslo find out more about both companies and our tech-lovin’ ways at and

Selecting the Right User Research Method

User Research can make a huge difference in the success of a product or service. When we understand the behaviors and goals of our users we are in a better place to server their needs. With so many methods and User Research tools out there, how does a person know which tool to use and when?

User Research tools

Have you ever found yourself trying to hang a picture, only to realize that you don’t know where your hammer is? You dig around in the junk drawer for a moment before realizing you left it out in the shed. Rather than put your shoes on and go get it (cuz, ugh, outdoors), you instead do what any right-thinking person would and grab the next hard object you can find, then spend 20 minutes smashing the nail into a wall with a wrench. This ultimately results in a bent nail, a dinged up wall, and you, resignedly walking out to the shed to go get the right tool.

Applying the wrong method when conducting user research is a lot like hammering a nail with a wrench. While a wrench is a great tool for certain tasks, it’s just not the right one for the job at hand. Similarly, you would not attempt to loosen a bolt with a hammer…unless you were like, the worst mechanic ever.

These days, most people have some idea of what user research is, its purpose, and the value behind it. They get that it helps mitigate risk, validates assumptions, guides the prioritization of features, increases the likelihood of product adoption, etc ..the list goes on and on. Unfortunately, the general perception of user research is often confined to a just a few strategies, such as surveys or product testing. While these tactics are not without merit, and certainly provide a level of both quantitative and qualitative value, limiting the scope of your research initiative to these few strategies will result in many metaphorically bent data-nails. Not all methodologies work for every app, user group, or situation. To successfully understand your users, you’ll need to employ right tool based on the research goals you are trying to achieve.

For Example…

A new client recently asked us to send out a survey that would help them understand what their users were thinking while trying to accomplish a certain task. Up until that point, this particular client hadn’t engaged with their users very much and this initiative represented a step in a positive direction; a step towards user-centered design. Sounds great right? After all, any time you can talk to actual users is a win, so conducting a survey to understand their needs would probably be helpful. Well…sort of…

We certainly could have sent off a well-crafted survey, asked all the right open-ended questions, and vetted the thing left and right to rid it of any shred of bias. In the end though, it wouldn’t have mattered. Not because surveys are a bad way to gather data, but because in this case, they simply weren’t the right tool for the job.

User Research and Data Types

To understand why this was the case, we first need to understand the type of data we were looking for. According to Indi Young, user experience consultant, author, and founding partner at Adaptive Path, user research data can be grouped into three categories: Preference, Evaluative, and Generative data. Each one of these data types comes with different issues and require different techniques for extraction. Preference data refers to the opinions, likes, and desires of users, generative data relates to the mental environment in which users get things done, and evaluative data pertains to what is understood or accomplished with a tool.

The chart below covers each of these data categories, the best techniques for extracting that type of data, and their ideal uses.

Indi Young Research Method Types

Young, Indi (2008-02-01). Mental Models Rosenfeld Media. Kindle Edition.

What our clients really wanted was to understand how their users think, their philosophies, motivations, and environments; all examples of generative data. As you can see in the above chart, surveys are a great tool for determining user preferences, or providing demographic information, but they aren’t ideal for gaining an understanding of users’ mental environments.

Employing The Right Tool

After further discussion and collaboration with our client, we decided to conduct non-directed interviews with eight of their users.

During the interviews, we stepped back from the client’s current solution and instead asked users to talk about their roles, allowing the conversation to evolve naturally. The user led the discussion, we actively listened, and asked follow-up questions based on what we heard. We used their words, expressions, terms, and tools, being careful not to introduce our own references.

The results were very insightful. By having this open conversation, guided by the user, we were lead down paths we didn’t even know existed. Prior to the interviews, we had no real information about the users’ mental environments. Through our generative research however, we discovered that these users actually had several different roles, with distinct needs, and that they were approaching the problem space from a completely different direction than our client.

Using the right approach, we were not only able to find out how our client’s users organized material, but we also gained a bunch of other valuable business intelligence. After meeting with the client and presenting our findings, we were left with multiple action items we could pursue:

  • Explore the distinct user roles
  • Prioritize which role to focus on first
  • Address our user’s pain point of lack of time
  • Add data to our proto-persona and lay the groundwork for building our UX personas
  • Use the correct terminology in future prototypes

All information we couldn’t have gotten through a survey.

Moral of the story: Take the time to put on your shoes, go out to the shed, and grab the right tool.

To learn more about UX methodology, check out UX Design: People Over Features, Outcomes Over Output.


Climbing Mountains With Agile Methods

Agile methods strive to break large goals into smaller achievable parts. In this post we will cover some high level concepts that have made it easy for us to achieve some big goals for our clients.

agile goalsBig goals, in many ways, are like mountains. They are daunting, arduous to climb (and well worth the view from the top). They capture our imagination and inspire bold action in ourselves and others just by being. Many gaze up at their peaks determined to reach the summit, but all too often, fall short for one reason or another.

Our struggles maintaining motivation when taking on large initiatives often stem from over-focusing our energy and attention on the end result, rather than the next step we must take to get there. We can get so overwhelmed by the sheer size of what lies ahead, frustrated by slow progress, and tripped up by unexpected pitfalls, we become demoralized long before we ever get close to the finish line. When this happens, it is because we have forgotten that big things are never accomplished with a single herculean effort; rather, they are overcome in progressive iterations – tackling a series of smaller tasks that bring us one step closer to the summit.

Agile Goals

When you break large objectives into small, measurable, achievable tasks, suddenly the mountain doesn’t seem so insurmountable. You start to think, okay, yeah…I can do this. Taking the journey step-by-step will will allow you to adapt when plans shift and celebrate milestones along the way. Side note: Seriously, don’t forget to celebrate the milestones – they are critical for maintaining morale and reinforcing positive change. This isn’t to say you should allow yourself to lose site of the big picture, just don’t let the magnitude kill your momentum.

This deliberate, iterative approach to “mountain” climbing is the same one we teach our clients and practice ourselves here at LeanDog. Here’s how it works: when someone comes in looking for help, whether for coaching or a development project, we always start by first assessing the situation. We explore every facet of their initiative to define where it is they are trying to go, the resources they have to get them there, and the struggles they may be facing. We also challenge assumptions and test hypotheses to uncover areas of risk hidden in their way. In doing so, we break their mountain down into a big pile of small, achievable objectives. We collaborate with them to prioritize those objectives and, through progressive iterations, we are able to carve out a path up the mountain together. The result is a clear direction, measurable progress, mitigated risk, and the overall feeling that yeah…we can do this.

By breaking down your large initiatives into smaller, achievable steps, challenging assumptions, celebrating milestones, and prioritizing tasks of highest value, you’ll find that what once seemed to be an impossible undertaking, is anything but. Before you know it, you’ll be enjoying the view from the summit and gazing confidently toward your next mountain.

How do you and your team achieve your biggest agile goals and initiatives?

To learn more about how Agile processes can help you climb your mountains, download a free copy of the LeanDog Agile Discussion Guide.

LeanDog Does CodeMash 2016

It’s time for another great LeanDog tradition: CodeMash!!!! Every year, our developers and designers don their fuzzy hair hats and descend on Kalahari to drop knowledge bombs all over the place. If you happen to be in attendance at CodeMash this year, be sure to check out some of the cool talks our folks have put together:

Acceptance Test Driven Development by Example with Cucumber – Part 1 & 2
January 5, 2016 8:00 AM and 1:00 PM
Speakers: Doug Morgan
Room: Salon H
Tags: Ruby/Rails, Testing
Category: Pre-Compiler

Are you a developer or tester who wants to help prevent bugs instead of finding them? Have you heard of Cucumber and wonder what it was? Then this session is for you! Automated testing is taking over the software industry, however writing tests after development is done only is the start of it. When developers, qa, and business owners kick start features by creating and automating test cases together, the team gets the added benefit of building the right functionality. This hands on workshop will have attendees working through examples using ruby gems, such as Cucumber, Watir, and PageObject, and will cover core concepts such as creating automatable acceptance criteria, how to keep your test suite clean, and interacting with web browsers and other media types. Walking away with working examples and references, each attendee will leave with the ability to further build on the topics covered.

Let’s Build a Hybrid Mobile App!
January 5, 2016 8:00 AM
Speakers: Kyle McKee
Room: Salon D
Tags: JavaScript, Mobile
Category: Pre-Compiler

Have you been telling yourself you’re going to do mobile, but never got around to it? Wouldn’t it be awesome if you could leverage your existing web skills to quickly build native mobile apps? In this workshop we’ll do exactly that using Cordova. Cordova is a platform for building native mobile applications using HTML, CSS and JavaScript. By the time you leave this workshop, you’ll have built an app that can be deployed to iOs, Android, and just about any other mobile device.

Using Lightweight Methods to Drive Your Designs Forward – Parts 1 & 2
January 6, 2016 8:00 AM and 1:00 PM
Speakers: Nicole Capuana
Room: Salon H
Tags: Testing, Mobile, Design (UI/UX/CSS), Soft Skills / Business
Category: Pre-Compiler

Product teams these days need to be moving quickly and iteratively in delivering great products. At times though, teams can get stuck on how to move the designs forward. Sometimes it’s because of unexpected complexity and other times there are multiple paths to explore. In this workshop, participants will experience a variety of methods that help teams gain a shared understanding through collaboration with clients, product owners, and key stakeholders. Each of the methods covered are lightweight and can be adopted by teams at any stage in the product design and development. Learn how to: get started with user research, define personas, generate and turn ideas into solid solutions, create low-fidelity mockups that can be tested with users immediately, conduct a usability test, synthesize your findings, and gain focus for the product through games and structured discussion. Every method covered will focus on designing a mobile app so that participants get the full experience of how each method fits into designing a product. Don’t worry if you don’t have any UX background, this workshop will guide you through exercises. And if you’re a UX rockstar, come flex your usability prowess with other professionals. Come learn and share tips & tricks! Everyone on a product team can benefit. from this hands-on practice.

Software Development Lessons Learned from Industrial Failures in the 1980s
January 8, 2016 12:15 PM
Speakers: Charlotte Chang
Room: Aloeswood, Leopardwood
Tags: Other, Testing, Design (UI/UX/CSS), Soft Skills / Business
Category: Regular Session

In the mid-late 20th century, industry giants asked themselves; “How do we continuously improve?”, “How do we build a quality product?” and “How do we design for end users?” These are the same challenges that we face as software developers and designers today. Issues with technical innovation, resource constraints, and organizational support, are experienced not only in zeros and ones but on the road and in space. In the early 20th century, the U.S. was considered a global leader in economic and scientific achievement. After those major innovations in transportation, space exploration, and computer science, American industries focused on manufacturing advantages, such as mass production and repeatable use. Progress was now measured by process improvements, adapting to market changes and ability to pivot. Why has the tech industry continued to boom, while other industries struggle? Using examples from General Motors and NASA, this talk examines their failures in reliability, collaboration, and product design. Take a step back in history to relive the experiences of these pioneers, learn from their past failures, and how they apply to crafting software products today.

Worthless story card estimates
January 8, 2016 4:00 PM
Speakers: Mike Kvintus
Room: Zambezi
Tags: Other
Category: Regular Session

How much of your time is wasted estimating story cards? We’ll explore some alternatives to estimating story cards and review real-world comparisons of tracking work using story points vs. counting story cards. Not sure when story card estimates are needed? We’ll discuss that too. Are you wondering if there is a better way to estimate projects that takes less effort but isn’t just a WAG? All discussions will be based on real-world examples and comparisons of alternatives for several projects. We’ll also discuss #NoEstimates and how it fits in. You’ll leave with an understanding of ways to plan/track agile projects and the tradeoffs involved with alternatives to story card estimates. The goal is to enable you can plan/track agile projects with less effort using methods that work for you.

IoT Course Week 3: Publish/Subscribe and Message Queues for Integration

Screen Shot 2015-10-15 at 3.07.21 PM

Demoing Previous Week’s Work

Students began the week by demoing their assignment from the previous week – building a  Kivy/Python touchscreen application (see previous post Week 2) to control the Hue, Saturation, On/Off, and Brightness of LAMPI.  The Kivy/Python application changes the PWM hardware signals, based on user interactions.

Screen_Shot_2015-08-28_at_1.41.45_PM (1)

That was a good first step, but, unfortunately, is exactly how we might have built an embedded product like that ten or fifteen years ago – a User Interface (UI) directly manipulating hardware.  That architecture starts to fall apart as soon as an additional UI (say, a web or mobile client) or a service (say, an analytics system) needs to be integrated.

Publish/Subscribe Architectures

When we want to add another “client” of the system, like a web page, we have to rethink our architecture – the UI directly manipulating the hardware is too limiting, and drives us to a client/server model.

There are a few common and obvious client/server models:

We decided to pursue a Pub/Sub model to give the students hands-on experience with this increasingly popular model for IoT.  Pub/Sub architectures tend to be loosely-coupled and are inherently asynchronous, making recovery from offline modes arguably more natural than with RPC or RESTful architectures.

There are a number of PUB/SUB protocols available – we chose to use MQTT, a machine-to-machine (M2M) Pub/Sub standard designed specifically for IoT.  MQTT relies on a “broker”, like most PUB/SUB protocols – a service to which all clients connect.  We chose to use the Open Source Mosquitto MQTT Broker, which is well-supported on the Raspberry Pi, and is being actively developed.  Other brokers are also available, including from IBM, and HiveMQ.  Recently, Amazon Web Services announced Amazon IoT, which also includes an MQTT broker service.

In MQTT, Clients Publish Messages on Topics by sending them to the Broker.  Messages are any string of bytes – you could use XML snippets, JSON, or your own custom binary or text solution.  For this course, we used JSON, a data serialization format that uses human-readable text to transmit data objects consisting of attribute-value pairs, to represent the lamp state (Hue, Saturation, Brightness, etc.).  Messages are Published on a particular Topic – which is just a text string (UTF-8).  Clients Subscribe to Topics. The Broker will then deliver an incoming Message to all Subscribed Clients.

Screen Shot 2015-12-14 at 9.29.49 AM

For example, when a user changes the Hue of the desk lamp with the Kivy/Python touchscreen application, a JSON Message like:

{‘color’: {‘h’: 0.5, ‘s’: 0.5}, ‘brightness’: 0.1, ‘on’: True}

(“h” for Hue, “s” for Saturation) is published on the Topic:lamp/set_config

The students were tasked with creating a lamp service to serve as an abstraction layer between the hardware and the user facing software (command line, Kivy). This service will act as the single point of truth for the lamp. The lamp service is responsible for translating the MQTT messages into hardware actions, such as receiving a color change message and sending the hardware PWM commands to control the led. They constructed a simple python implementation of this service using Paho, the MQTT client library for Python. In addition to submitting their code, they had to upload a video to demonstrate the tool’s behavior.

Some commercial systems that leverage MQTT include Facebook Messenger, Amazon (mentioned above), and the EVRYTHNG IoT platform.

What is up next?

To the cloud! Next week, the students will be introduced to general cloud concepts and providers. Next, they will dive into Amazon Web Services by building an EC2 instance that will host a second MQTT broker. From there, the students will be dealing with more advanced MQTT configurations by bridging the MQTT broker on LAMPI and the MQTT broker on EC2. Along the way, Unix daemons will be created and managed.