Internet of Things: Connecting the Physical World to Your Business

Leverage the Internet of Things (IoT) to make the ever-growing network of devices talk to existing services or new products.

Companies are looking to use Internet of Things (IoT) to connect, modernize, or invent services and products. Extremely large volumes of sensitive data come out of IoT ecosystems. Preparing for how you plan to use and secure the data are essential conversations to have from the start.

See how Trility helped three clients build new products and services, expand solutions, and invent new ways to create efficiencies and experiences to their customer’s delight.

When we needed a team that could come in with practical solutions to our aggressive goals, we went with Trility because they offer predictable, repeatable software development processes that can scale to our needs.

Jesse / Samsung SmartThings

Go For The Win

The “fail fast, fail often” mantra may NOT lead to a win in the world of digital transformation. Just like in soccer, your company must focus on the desired outcome (scoring goals) to win.

The mantra “fail fast, fail often” is a rallying cry for technologists pushing organizations to become more Agile, more Lean, and to push teams to deliver faster. What is being delivered and how valuable it is long term, however, tends to get lost in the shuffle and “fail fast, fail often” can lead to a big fail when there isn’t a clear goal in mind. 

The 2019 FIFA Women’s World Cup was held in France and if you’ve watched any of the games, one of the statistics talked about is time of possession. During the course of a game, teams will drive forward to test an opposing defense, then pull back, sometimes all the way to the goalkeeper, and try again. However, as soon as the defense has adjusted and passing lanes are open the offensive side is on the attack again working towards the desired outcome: Score a goal.

Fail fast, learn often may not lead to a win in the world of digital transformation. You don't win if you aren't focused on taking shots at the goal. The first step is defining the desired outcome.
Fail fast, fail often may not lead to a win in the world of digital transformation. You don’t win if you aren’t focused on taking shots at the goal. The first step is defining the desired outcome.

In April 2018 Sunnie Giles, a Forbes.com Contributor, posted an article: How To Fail Faster – And Why You Should. She states, “In today’s complex business environment, where things are changing constantly, speed of execution is a lot more important than perfect execution.” She points to a concept of iterations creating positive autocatalytic feedback loops which eventually leads to radical innovation. This is a pretty common view from many leadership teams on how they want to push their organizations forward.

Radical Innovation

The words “radical innovation” stuck out when I read the article. I have had the privilege to work with a number of organizations throughout my career. In some cases, the leadership inside the organization coveted innovation and spent a significant amount of time and money building up innovation teams. The opportunity to drive the business into adjacent markets, new markets entirely, or to refine their existing market offerings to expand the organizations hold on a market. More often than not, the “radical innovation” introduced by leadership was either cut off from the rest of the organization or was actively under attack by more established parts of the organization and in the end, not effective in achieving the original business objectives.

Teams get locked into playing possession and lose focus on moving down the field and scoring a goal.

7/2/2019 World's Cup Score: England Vs. USA
Above is an illustration of losing focus. In last week’s game, England had more possession, more passes, and better passing accuracy, but because they didn’t attack they lost the game.

Why? Executives jockeying for power, friction between “the way we’ve always done it” vs. “the new way we want to do it now,” shrinking budgets, changes in priority to shore up existing market share. A large number of different factors all branching from a common thread: a lack of focus on the desired outcome. Teams get locked into playing possession and lose focus on moving down the field and scoring a goal.

Four Steps to Fail Fast AND Achieve the Desired Outcome

How do you prevent getting locked into playing possession? At Trility, we break the process down into four distinct stages: 

1. Discover
2. Definition
3. Implementation
4. Evolution 

Each stage in the process has a clearly defined outcome to help ensure stakeholders can see the value along the way. Often companies are eager to jump straight to the Implementation stage and the “fail fast, fail often” mindset can achieve the discover and define stages – thus the desired outcome along the journey. However, unless you know where the goal is your team is just playing possession.

FIRST Robotics and Giving Back

None of us are getting any younger. And to see the type of people, teams, companies and world in which we want to live today and in the future, we have to give back to communities and people in a way that positively influences generations after us. No matter how big or small, taking the time to help others matters.

Trility Consulting is proud to sponsor Des Moines, Iowa area Team 4646 ASAP as they head to Grand Forks, North Dakota this week to compete in the FIRST Robotics Competition! FIRST Robotics teams this year are building robots to compete with this year’s challenge DESTINATION: DEEP SPACE presented by The Boeing Company.

Teams that choose to compete in the FIRST competitions are given a six-week time limit to design, build, and program industrial size robots to play a field game against other teams. In addition to the building the robot, teams raise funds, design a team brand, develop engineering, business, and marketing skills working with volunteer mentors. In essence, young folks are learning how to create a working product, make time-based decisions and build an operational model which will serve them well as they figure out how to make their mark on this world through the years.

And Trility Consulting is additionally working with other Robotics teams in the area as well. Eric Gerling, Trility’s CTO, actively volunteers with the West Central Valley High School Robotics Team each year. Known as The Breakfast Club, the WCV Robotics Team competes in the FIRST Tech Challenge and completed their most recent season last December 2018.

While we’re all busy pursuing our careers, working to make money and improve the lives of ourselves and our families, don’t forget to take the time to think about the people that come after us. It takes much less effort than you imagine to be an encouraging teammate, coach, teacher or friend. And while the time investment may seem big to you, the return on investment in the life of one young person could very easily be a lifetime of success and opportunity.

Don’t Forget the “V” in MVP

Security, operational readiness, reproducibility, and scalability are all important parts of any product, which helps validate the viability of a product. Unfortunately, in the race to production these items fall by the wayside and show up on the backlog.

Securely develop products

Minimum Viable Product, or MVP, is a common term used by business leaders and product owners to help drive quick, iterative, product development to get products released to market faster. The goal is to release just those core features necessary to put the product in front of customers to learn about customer needs and validate assumptions prior to larger investments in a new product. Release quickly, release often, and adjust the product based on feedback from customers.

Product teams today do a great job of focusing on the M, Minimal. Constantly asking the team and business stakeholders when new feature requests are made, “Is this a requirement for MVP?”, helps prioritize development efforts and keep the team focused on making a timely and relevant release. Business stakeholders on a regular basis can see the features being developed during frequent demos and can provide direct feedback which goes back through the same intake process grounded by the same question focused on releasing the MVP. When the cycle is managed by a proactive Product Owner, it can be an extremely efficient way to get ideas from a napkin at lunch to a product in front of customers.

Where Product teams struggle is with making sure the V, Viable, is taken into consideration as a team. Security, operational readiness, reproducibility, and scalability are all important parts of any product which helps validate the viability of a product. Unfortunately, in the race to production these items fall by the wayside and show up on the backlog. When the team does release the product and receive customer feedback, they’re often stuck in a challenging position of either picking up the items in the backlog tagged as After MVP or continuing to refine the product to keep customers engaged. As it should, the focus remains on the customer and meeting the business objectives for the product. The weight of the backlog eventually causes cracks in the team, cracks in the product, and a new round of questions for business stakeholders to consider regarding whether to refactor, rewrite, or sometimes, a new MVP to fix the problems from the previous MVP.

Continuous Integration, Continuous Deployment, Security by Design, Test Driven Development, Performance Testing, Infrastructure as Code – these are all terms many development teams are familiar with and actively promote inside organizations today. However, many of these items are the first things added to the backlog during MVP development when teams are racing against the clock. We need to do a better job as Engineers communicating to business stakeholders that each of these items are individually, and collectively, an important part of making a product viable.

We can still meet the needs of a minimal product by constraining the conversation in each case to the product being developed. The product may not have a need to support a thousand requests a second for the MVP, but we should ensure performance testing frameworks are in place and exercise the product on a regular basis so issues can be discovered early and often during the development process. The product may only require a small amount of simple infrastructure to be deployed to support the MVP, but the infrastructure should be built and deployed in code alongside the rest of the product so as needs change the foundation is already in place to support rapid growth. The product may not have a requirement to support a security standard for the MVP, but the application should be built following a set of standard security practices and validated regularly with automated testing to support a growing customer base. 

Viable – the ability to work successfully and securely.

Product teams need to ensure when MVP is defined, the product’s ability to work successfully after release is front and center during the development process. Minimal helps you get to the first release; Viable ensures you make it to the second.

Do You Understand Time to Value?

The definition of value is subjective. Measuring expenditures is objective. If you ask someone in your company or team to define value, what do you think they will say? Will they discuss financials? Will they discuss projects, software releases or widgets created? Do you or your team define value to a customer by counting things?

As a quick exercise, define the value of your pants; not in terms of money, but in terms of value to you. Simply put, can you measure the value of your pants? Simpler yet, define the word itself — value. Like choosing wine, art and music, defining value is subjective to whomever is shopping.

In business, we use cost accounting to count things. Ironically, cost accounting does not define value for a customer, nor does it delight a customer. It simply counts things.

When we use cost accounting to measure, we’re being fiscally responsible. However, the focus on the cost of things leads companies, teams and individuals to perceive that cost of acquisition, cost of ownership and return on investment math defines value. While the company that sold you pants can measure their investment throughout the entire supply chain down to the point of sale, that math doesn’t define how you value pants, their brand or company. Were you able to measure the value of your pants? What would make you purchase a second pair of those pants?

Taking software projects and breaking them down into people, time and cost helps us count things. In order to deliver product and service solutions to customers, we count things. Does that seem weird? Does it seem weird we can count all of the things in a project, feel good about ourselves, and still have no idea what the customer actually values?

Does knowing the cost of all the things in a software delivery chain mean we know when we’ve provided value to the customer? Unfortunately, it does not. It only suggests we know how to count.

If we can objectively count money, but we cannot easily measure a customer’s perceived value of things, as business and technology leaders and team members, how do we increase the probability of making first-time and recurring sales? Most of us are in business to make a living. Making a living requires money, which requires sales. If we don’t know what a customer values, how do we make sales?

“What!?” you say to me. “I’m not a sales, advertising or marketing person. That’s their job to do that rubbish. I just deliver stuff.” I’m not a marketing, advertising or sales expert either. However, for those who are, as a technology leader I can help them do their jobs better by providing shorter time to revenue windows which helps them discover shorter time to value windows for both the company and the customer.

In other words, marketing, advertising and sales people need options every moment of every day to adapt to varying customer scenarios, gain market-share, crush competitors and make money to pay our salaries and business expenses. And they need them now, not when the business and/or technical teams can get to it.

What is the time between having an idea and delivering the idea in order to delight a customer and generate revenue?

In your company, is the flow of a product solution from beginning to end smooth like fresh ice on a hockey rink and as fast as a hockey puck? Or is it more comparable to the starts and stops of a muddy, variably pothole laden road? Figuring out time to revenue and time to value factors depends on understanding how product solutions flow through your company.

If you build software solutions and/or run software operations for a living, what do you think about the following questions?

  • Why are there so many steps to get from idea on a napkin to implementation?
  • Why are there so many tools in the delivery chain?
  • Why does it take so long to find out if we broke something that worked yesterday?
  • Why can’t we know whether the product meets company standards all of the time?
  • Why do we test so late in the process potentially delaying our project?
  • Why can’t we know if we’re compliant with industry regulations every time we build software, every day of every week instead of during third-party audits performed quarterly and annually in arrears?
  • Why can’t we deliver small portions of the larger solution that can be marketed, advertised and sold along the way instead of waiting for everything to be finished before we can even begin advertising, selling and making money?
  • Why can’t we find a way to deliver at the highest quality and highest velocities at the same time? Why are they treated as mutually exclusive?
  • Is information security and performance really something I have to kick down the road until later?
  • Why does it seem like our projects are black boxes of magic until the very end?

Consider this: Sales people are expected to provide verifiable value that is daily, weekly, monthly, quarterly and annually measured in qualified leads, follow-ups, sales and revenue with non-negotiable baseline margins, but people who build software products take as long as they take and spend as much as they spend?

If you're responsible for delivering solutions that enable customer delight resulting from sales, marketing and advertising successes, the distance between having an idea and realizing the ability to make money with said idea is called -- time to revenue. 

The distance between having a product and knowing what product the customer actually wants to buy is called -- time to value.

Question: Organizationally and operationally, what do you need to change in order to realize shorter and more frequent time to value discoveries?

If you’d like help figuring out how to compress the time it takes to get from an idea to making money while also including security, performance, quality and reliability from the beginning (instead of later), we’d like to help. Or if you’d like help determining how to more quickly and frequently discover, re-discover and provide recurring value for your customers, the teams at Trility Consulting know how to help you get from where you are to where you’d like to go.

We evaluate your business goals and current state of operations. Then we work with you to implement solutions which help you get there. We use 100% software-defined, continuous delivery behaviors including continuous test-driven development, continuous inspection, continuous compliance, continuous vulnerability assessments, continuous penetration testing, software defined infrastructure, serverless architectures, secure enterprise-class cloud ecosystems and more. This is simply what we do and how we live even for our own projects — and we’ve been doing it for quite awhile.

We’ll help you discover what time to value looks like in your team and operation. And your customers will thank you for it.

ShowPal Launches Another Product

ShowPal, a Des Moines, Iowa based start-up founded by Chad Torstenson, recently launched its next product which enables showing a home without an agent or homeowner present!

Adding to the existing Property IQ product, ShowPal now provides the additional  abilities to list, show, buy and sell your home without an agent should you choose to do so. And if you decide a bit of help along the way would be handy, ShowPal will provide the additional service of a broker!

The ability to perform autonomous home showings is the next in a series of products and services planned by ShowPal designed to make the process of selling, showing and buying properties safer, easier and cheaper for everyone involved.  To custom build these products and services, ShowPal engaged Trility Consulting, of Urbandale, Iowa, to help design, build and deliver their cloud and on-premises based software solutions. 

Trility Consulting focuses on helping companies adopt, build and operate in secure enterprise cloud ecosystems so companies can focus on serving customers.

Visit ShowPal’s site! Or stay in touch with them on Twitter  and Facebook!

ShowPal Launches Second Product

ShowPal, a Des Moines, Iowa based start-up founded by Chad Torstenson, recently launched its second product named ShowPal Home IQ!

ShowPal Home IQ is an Amazon Alexa Skill that works with the new Amazon Echo Show.  Using ShowPal Home IQ, Alexa is able to provide potential homebuyers on-demand answers to their questions — all while touring the listing.  ShowPal Home IQ is also able to send important property documents to interested buyers or the buyer’s Realtor on request.  

“Knowledge gaps about a property are common and this understandably leads to questions from a home-buyer.” says Chad Torstenson, ShowPal’s Founder and CEO.  Simply, “We want buyers to leave a showing with offers, not questions.” says Torstenson.

With ShowPal Home IQ, buyers can ask Alexa about the home’s utility costs, comparable properties in the area, local schools or details around a home warranty.  If a potential buyer wants to review the homeowner association documents before they consider an offer, Alexa is ready to answer.

Home IQ is the second of multiple planned solutions by ShowPal designed to make the process of selling, showing and buying properties safer and easier for everyone involved.  To custom build these products and services, ShowPal engaged Trility Consulting, also of Des Moines, Iowa, to help design, build and deliver their cloud and on-premises based software solutions. 

Trility Consulting focuses on helping companies adopt, build and operate in secure enterprise cloud frameworks so companies can focus on serving customers.

Visit ShowPal’s site! Or stay in touch with them on Twitter  and Facebook!

 

Iowa start-up launches new product!

ShowPal, a Des Moines, Iowa based start-up founded by Chad Torstenson, recently launched its first product named ShowPal ID!

ShowPal ID, the first of multiple products and services planned by ShowPal’s CEO, is designed to enable increased safety for Realtors as they meet and interact with clients who often are not personally known to them.  ShowPal ID performs on-the-go identity verification of homebuyers on behalf of real estate agents in advance of engaging with a client so that all parties know who is involved before they meet for the first time.

“Every year real estate professionals are placed in harms way by individuals fraudulently posing as a prospective client.  The statistics of crimes committed against Realtor’s such as robbery, physical assault, sexual assault and homicide are staggering. We intend to change that,” says Torstenson. 

In order to accomplish the goal of building software solutions for the Realty industry, ShowPal engaged Trility Consulting, also of Des Moines, Iowa, to help design, build and deliver a cloud-based software solution that seeks to address a very important problem in today’s real estate marketplace — the safety of Realtors and Buyers.

Trility Consulting focuses on helping companies adopt, build and operate in secure enterprise cloud frameworks so companies can focus on serving customers.

Visit ShowPal’s site! Or stay in touch with them on Twitter  and Facebook!

Update: In the true spirit of a start-up’s need to test, learn and refactor, ShowPal published and tested ShowPal ID and determined that while an important problem to solve, this product doesn’t meet ShowPal’s own requirements for viability. Resultantly, this product has been put to sleep with the potential of re-launching in the future if and when it makes sense. It is hard to build and deliver product.