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!

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.

IoT Course Week 2: User Experience and User Interfaces

Screen Shot 2015-10-15 at 3.07.21 PM

The focus of Week Two centered around applying User Experience Design concepts to the development of connected systems.

Demoing Previous Week’s Work

Students began their second class by performing a demonstration of their first assignment. Each LAMPI had to to able to turn off and change color from red, to green, to blue, to white. Prior to the start of each class, students are required to submit their source code and upload a short video demonstrating the required functionality, as well as answers to any assignment-specific questions. This is done to ensure a universal understanding of the material, and to provide an opportunity for any clarification that might be needed.

User Experience Design

Students were given a rapid introduction to User Experience Design (UX) by Nicole Capuana, one of LeanDog’s resident experts on the subject. Her lecture explored the many challenges and opportunities that can arise when designing systems, especially when it comes to UX for IoT. Students learned that UX is about crafting an overall experience from multiple moving parts which, when done right, work together behind-the-scenes to enable users to interact seamlessly with a given system. Her lecture challenged students to “get out of the building” and actually interact with users rather than just assume people will behave according to predictions or like them. She also encouraged the students to test their hypotheses frequently, measure the results, and analyze their data, to ensure that they are creating a product that people love.

UX for IoT

When building a user experience for connected systems, particular attention should be paid to crafting a seamless experience. Working with something as commonplace as a lamp, the end user already possesses deep seated expectations about how it will work and behave. It is the job of UX to ensure that the connected functionality of the lamp will augment existing expectations, not upset them. A connected device often promises to be smart and learn over time, so it’s imperative to carefully craft the design of the device working with minimal errors or the need for the users to intervene. Method of control, physical and digital interaction, contextual awareness, and first-time setup are just a few of the many things to consider when approaching UX for connected devices. Themes introduced during this lecture were revisited throughout the remainder of the course.


To provide a manual method for controlling the lamps, students attached PiTFT touch displays to the lamp base (pictured below), and configured the screens to work with their corresponding Pi’s. They then used Kivy, an open-source Python framework for the rapid development of applications that rely on UI’s, to begin constructing the interactive interface of the touch screen display.

Kivy was chosen for many reasons. It is a modern UI framework that supports hardware acceleration, is touch optimized, and supports animations. In addition, it is cross-platform, open source, built for Python, and is MIT licensed. Kivy’s separation of UI and program logic, as well as its concise markup, has enabled us at LeanDog to employ it in prototyping client work. These traits form a system that allows a cross functional pair of a designer and a developer to rapidly build and test experiences around an implementation.

In preparation for this lecture, Nicole Capuana and Gary Johnson, a developer at LeanDog, paired to iterate through the design of the Kivy UI for LAMPI. They used a collaborative, low-fidelity exercise to build out the iterations using pen and paper mockups; demonstrating that with simple tools and teamwork, you can work through designs quickly. Students were shown the versions Nicole and Gary worked through and then were given a mockup of an initial UI to implement and begin experimenting with.

Screen Shot 2015-12-08 at 9.56.24 AM Screen Shot 2015-12-08 at 9.56.41 AM

After building their own UI’s in Kivy, the students learned how to enable their software to control the hardware of the lamp. The end result was a working lamp controlled by a touch display which allows the user to change the hue and saturation of the lamp color, adjust the brightness of the lamp via Pulse Width Modulation (PWM) (see the previous post), toggle the lamp On and Off, and have the display show the current color of the lamp.  

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

What is up Next?

Next week, students will forge onward in implementing some of the more technically advanced communication patterns to be used throughout the development on LAMPI. With the UX process fresh in their minds, students will be required to adopt a critical and iterative process aimed at improving interactions between humans and LAMPI. Utilizing the UI framework Kivy, students will build an initial user interface, paving the road for early hands on user testing. Throughout the remainder of the course, students will continue to receive practice in toolchains commonly used across professional software development teams.  

Professional Development Hack Days at LeanDog

There are a number of fields in which ongoing professional development is not simply a job requirement, it’s the only way to stay relevant in an industry that is perpetually evolving. The highly technical world of software development is no exception. Coders, designers, and engineers of all programming languages must continually update their skill sets just to keep pace in a field where technology evolves seemingly overnight and market trends are constantly shifting underfoot.

As essential as this constant professional improvement is for the individual developer, it is absolutely critical to the survival of a software studio. Design and delivery studios depend on competent, creative, T-shaped craftsmen to drive innovation and produce cutting-edge products. However, in busy shops like LeanDog, where developers are routinely tackling complex scenarios, it can be a challenge to find time to pick up a new skill or enhance an existing one.

So how do you help your development team diversify their skill sets when client demands dominate the majority of their time? One way is for leadership to actively create opportunities to learn something new in an environment free of the pressure to “get it done.”

So that’s what we did! Last Friday, the LeanDog Studio took a break from their many projects and joined forces to try something new: a Professional Development Hack Day.  This session had three overarching goals:

1) Learn something

2) Share Something

3) Have fun

Prior to Hack Day, the Studio came together and pitched nine project ideas. They then took a vote and ended up choosing four to pair on:

  • Unity as a rapid-prototyping tool
  • Indoor navigation with iBeacons
  • Deployment pipeline with Docker
  • Conference outline – UX Survival in Agile

After the monthly company meeting, studio members teamed up with co-workers they are not normally pairing with and spent the next four hours “nerding out” (a highly technical industry term) on their respective projects, the summaries of which are listed below. At the end of the day they regrouped for a Show and Tell and voted on which project took “Best in Show”.  Everyone had a blast and learned some pretty cool stuff in the compressed (but relaxed) format.

The Projects:

Unity as a Rapid-Protoyping Tool

Will Kesling pitched this idea to look for alternatives for prototyping game mechanics and solutions.  Our current tool for this is Gamesalad, which makes it easy to build quick prototypes, but limits our ability to modify the generated code for our purposes.  The goal of this session was to attempt to build a mini-game that would better suit our current prototypes.  Will Kesling, Bill Holmes, and Eric Hankinson teamed up and found that Unity was a very cool and powerful tool.  They built an interactive 3D world with converted 2D objects.  It was great to be able to write C# to handle some mechanics.  However, Unity is not well-suited for rapid prototyping.  The team suggested looking more into 3D Unity as a production-level framework and perhaps trying again with 2D Unity to see if it’s a better fit.  The team recommended starting with the asset store when you start a new Unity project. 

Indoor Navigation with iBeacons

Gary Johnson pitched the idea of mapping the boat (our office) and using locators on people and items.  Besides being cool, exploring this technology would help us understand installation type projects, like museums and trade shows.  Mike Kvintus, Nick Barendt, Paolo Appley, and Carl Shotwell ended up teaming up to map the boat using the estimote beacons we had on hand.  The team deployed the beacons, mapped the area, and started a swift app to display locations.  They found the estimote service and SDK to be difficult to use.  The software was buggy, slow and inconsistent.  Additionally you need at least 4 estimotes to map a room and they come in packs of 3.  The estimote mapping software was not a big fan of the irregular shape of the boat.  The team suggested getting more beacons to see if a larger area could be mapped and investigating alternative iBeacon technologies.

UX Survival in Agile

Nicole Capuana pitched working on a conference talk for Codemash that would describe how UX best fits into Agile Software Development.  The ultimate goal is to create a talk that would be reusable with multiple perspectives.  Steve Jackson and Charlotte Chang joined Nicole on brainstorming and talking through ideas that would make this a useful guide for UX practitioners in multiple uncomfortable situations.  The team also worked on a talk Charlotte is preparing on Software Development Lessons Learned from Industrial Failures in the 1980s.  The session was very productive and the team recommends that all speakers try to get differing perspectives for that post-abstract phase.  This collaboration helped raise the bar on what a really excellent audience experience could be.

Deployment Pipeline with Docker – “Best in Show”

Nathan Wallace suggested building multiple environments with Docker and testing each one with our continuous integration server.  If successful, this would apply to many of our current projects, allowing us to easily build and deploy new fully tested environments for all of our integration points (along with our tested code).  It also has the potential to reduce our need to configure and setup environments for our CI itself.  Nathan and Chris Nurre teamed up and were successful in building a Docker image for a vanilla rails install. With each pushed commit, a new environment was produced.  The team found that installing Docker on our heavily mac-based infrastructure was difficult, but was otherwise happy with the tool.  Their recommendation was that all of our web-based projects should default to using a Docker file for CI and that it would be useful to further investigate the Jenkins-Docker integration, as well as deploying the images using a Docker registry.

By taking a small break from “getting it done” and creating an environment focused solely on learning something new, we were able to provide everyone an opportunity to relax, expand their horizons, and bond with their co-workers. Overall, LeanDog’s first Professional Development Hack Day was a rousing success and the team is looking forward to coming together next month to do it again.