The right champion pays dividends

The right champion pays dividends

The right champion pays dividends

Written by Mark Van Driel

Over the last few years, I have witnessed many organizations invest in understanding their business, users, and customers prior to building their digital products. They start at the highest level, in what we call the innovation phase, drafting a concept from identified user needs. This concept verifies the value of the digital product, the engineering team then drives the entire product design from a user-centered approach. The typical outcome is a digital product that achieves its goals. 

During this same period, I have also seen organizations rely on key people in their organization to determine the needs of their business, users, and customers. These people, whom I refer to as champions, determine the capabilities of the digital product and fit the product to their view of what users need. The result of this approach typically is a product that falls short of its goals, while further challenging the relationship between the business and information technology teams.  

There are two primary reasons why the champion approach is used so often in software development – organizations do not want to bother users, or they think they do not have enough money to pay for formal design. Let’s explore why these reasons are flawed. 

“I do not want to bother my users or customers” 

It is surprising how often organizations use this argument to bolster the champion-based approach. The obvious problem with this excuse is that unless you understand what they need, it is difficult to build the right digital product for them. Not involving the users until the product has been programmed will most often miss the actual needs of the users. The product team then modifies the inadequate user interface in an iterative fashion until it is good enough for the users. Getting “good enough” instead of “just right” results in the users being bothered more than if they were involved from the very beginning. This constant misrepresentation of needs can also erode the businesses’ confidence in the information technology product teams. 

“It costs too much to pursue a user-centric approach” 

The reality of this statement is that people often fail to consider that someone will have to design it anyway. Won’t a designer be more efficient at design than an engineer or business analyst? What about the extra iterations of user interface modifications during the engineering phase, won’t that cost additional money too? The answer to both questions is yes. Additional efficiencies can be driven by design if you build a design system to be leveraged across the product, saving time and investment. 

All of this brings me back to the beginning. The champions in our business are important and often serve as the experts inside our organizations. But just remember if you are taking a champion-driven approach to designing your product, the real champions are the users and customers. Build it for them, with their input, and it will pay dividends. 

Recognition at SDG

Recognition at SDG

Recognition at SDG

At SDG, recognition and showing appreciation for each other has always been a natural part of our culture. To give proper kudos when they are due, we have a number of different recognition programs that are designed to show appreciation to employees that go above and beyond.  

Giving power to our employees has been the driving force behind our most successful recognition program, the High-Five. This highly utilized program allows employees to gift up to $50/month to their peers, to be used at their discretion.  Our employees have the ability to say thank you whenever, and to whomever, they want to. And they do so, frequently!   

We have a couple of quarterly awards, designed to recognize individuals who have done something to enhance either the experience of fellow SDG employees or our customers.   

The Ambassador Award recognizes those that embody and uphold our culture. Maybe they are a leader out on Slack, or they set up lunches and happy hours to connect with other employees. These are just a few ways our employees contribute to the culture. This award is one way to say thank you to those employees that continue to make SDG a better place to work.  

We also have a quarterly award dedicated to employees that go above and beyond for our customers. Through the Frankie Award, we can say thank you to individuals who have done so much for our customers.


And last but not least, we have an award that encompasses it all, our SDG Award! This is an annual award that recognizes those individuals who have done it all throughout the year. They have been an amazing employee dedicated to contributing to our culture as well as going above and beyond for our customers. To say thank you, we want them to take a little vacation or spoil themselves on something that is a bigger ticket item. It’s our way to say ‘thank you’ for all the hard work throughout the year. 

Recognition is an important part of any company culture and is something we strongly believe in at SDG. We are immensely proud of SDG’s culture and the work we do with our clients and these programs are one way we show our appreciation anyone that makes SDG an amazing place to work, and work with.  

Successful Digital Product Innovation

Successful Digital Product Innovation

Successful Digital Product Innovation

Written by Mark Van Driel

Building software to bolster the digital capabilities of your business is a costly and time-consuming adventure. Often the digital products that are created during this process fail to return the desired business outcomes, fall short of user (and customer) needs, and are difficult to maintain. Taking time to fully understand the opportunity provides the necessary space to innovate and achieve the goals that you seek. Creating concepts before building will help to validate your hypothesis while increasing the understanding of what will be built.



Innovate before you build

Here are the four key components of innovation that will dramatically improve the success of your digital products.

1. Align Stakeholders

Have you truly established your business and user goals? Does everyone have a clear understanding of the related changes and commitments that are required to achieving these goals? If they don’t have an in-depth knowledge of what you are trying to achieve, how can they possibly support it?

Using workshops and leader alignment sessions to kick-off a digital product initiative will pave the path to success. Continuing to engage stakeholders in key decisions as the product takes shape will ensure that the alignment continues for the life of the product.


2. Identify Business Goals

How many times have you heard that a business is building a digital product to grow the business? What does that mean? What measurement will be used for success? Is it simply revenue or do you consider margin? Is the goal the same for all of your company’s divisions?

Establishing clear desired business outcomes is critical for every digital product initiative. Not only does this provide a measurement of success, but it also acts as a guiding light for decision making and feature prioritization. As they say in the building trade, measure twice and cut once.


3. Understand User Needs

How can your staff completely understand all the of a user’s needs if they don’t ask them what they need? What is the business opportunity to optimize the experience for your users? Do you give them a chance to validate what they are getting before you build it? Or do you iterate numerous times in your build process to kind-of satisfy their needs?

Understanding the types of users you have, their daily workflow, and the specific needs they have provides the knowledge required to build a successful digital product. Engaging your users in a process of discovery, concepting, and validation will also drive a true partnership with the business.


4. Architect the right solution

Are you architecting a solution that can achieve the desired goals? Are you trying to leverage existing enterprise software even if it doesn’t fit? Do you have an understanding that a poorly architected solution can increase the long-term cost of the product? Are the desired outcomes even achievable for an investment that is in alignment with the business case?

Leveraging the business and user needs to derive the right architecture ensures that your digital product investment will not be wasted. Considering software packages, cloud native services, and custom software development investment in your architecture will ensure alignment to long-term business goals.


Preparing to build

After the first round of innovation, you can begin to plan for the building of the product. The target architecture and enterprise technology provide the foundation for process, visual, and technology-oriented frameworks. These frameworks are important to the success of the entire organization by providing consistency, reducing long-term cost, and the ability to increase the velocity of future build efforts.

Innovating before you build allows the development of valuable products while providing a roadmap for organizational transformation.

Getting comfortable with iteration

Getting comfortable with iteration

Getting comfortable with iteration

Written by Brian Ganas

There is a constant debate happening between the new way of thinking about development, typically agile methodologies, and the old ways of thinking, typically the beautifully named but oft-disparaged “waterfall.” The thing is: this debate isn’t happening much in a verbal space. Almost anyone you speak with is going to say out loud that waterfall is out and agile is in.

But this debate still rages on; it’s happening in the minds of every project manager, business analyst, and stakeholder. I guarantee it. The idea of moving forward with software development without knowing every single feature that’s going to be needed and/or created is a scary one.
Coming personally from a business analysis background, I share this fear. I start working on documenting what we need an application to do, and it’s a terrifying prospect to forego months of careful, considered planning and research. We’re just supposed to… start working?


Change the focus

The problem is a lack of understanding or comfort with the concept of iteration. When people think of software and iteration, they’re focusing their attention at the wrong levels. They are planning major version changes as iterations, each new release coming with a large set of deadlines, feature changes, and fundamental alterations to how the solution is going to work. Development teams end up caught in this line of thinking, believing that the only way we can start and work on a new solution is to identify each of these large iterations, research and document all the requirements, and then begin a development and testing plan.

We need to refocus the idea of iteration and make sure we’re looking at small-scale changes instead of large scale. The idea behind agile has never been to justify the idea that we can skip planning altogether. It simply reframes how we handle planning and research. We blend it together with the development process. We’re looking a few weeks, maybe even days, ahead as opposed to months or years. And we can do this because we get comfortable with iteration.

Act small, fix small

Agile encourages organic evolution of a software solution. Rather than adhering to blueprints that were set out months ago, we allow the software to grow within the environment in which it exists. Users provide feedback and we react to that feedback — quickly. We need to grow comfortable with the fact that we will make mistakes, we will add features we don’t need, we will release certain features that are incomplete or fail to deliver the best solution. Those are not failures within the process; those steps are a part of the process. But fixing those mistakes is a key behavior that allows agile methods to thrive. Iteration. Act small, fix small.

Changing to an iterative mindset

There are a few things I’ve enacted personally to try and effect a change toward an iterative mindset.

  1. The phrase “let’s try it” seems to unlock people’s inhibitions like nothing else. Encouraging the “let’s try it” attitude as a product owner, ScrumMaster, or SME gives a dev team permission to fail, and therefore permission to innovate and imagine. The solution may not always work or it may require significant overhaul later, but it gives the team the freedom to work on something knowing that the future is still unknown and that it is okay to explore ideas.


  2. Smaller stories. There are countless arguments for this objective in general, but making user stories smaller in the pursuit of iteration helps so much. A team member working on a smaller backlog item is naturally going to feel less pressure to ensure the work has achieved absolute perfection. Smaller stories naturally encourage iteration because they encourage, and often require, future changes on a more limited and more frequent scale.

3. Embrace the process. Don’t go into a sprint review or a meeting with the word “failure” attached to any work the team has performed. Apply positive associations with the attempt instead of negative ones. The cliche states that it’s only failure if you learn nothing. With a team ready to innovate and iterate, it’s virtually impossible to fail; you’ll always learn something from every work item. Learning what not to do with your software solution is just as important (more important?) as learning what to do.

4. State the obvious. It seems like such an easy answer, but actively speaking about the concept of iteration helps reinforce the practice of iteration. Talk about it during standups. Talk about it during sprint reviews. Report to stakeholders and customers that you engage in an iterative process, so change may be small, but it will be frequent and highly reactive when necessary.

5. Do not state blame. This one is easy and benefits a team well beyond the concept of iteration. When a feature doesn’t work as we hoped, do not blame anyone. Not the PO, not the developer, no one. Just move on and fix it. End of story.

6. Do not accept blame. This gets trickier, as now we’re interacting with external forces. When a new feature doesn’t work as planned, we also have to defend our team and our process by not accepting blame. We must own our mistakes and our process, but we have to reinforce the fact that an iterative approach means we may not have the solution perfected with our first attempt. Push back on blame. Mistakes and incomplete features are a part of the process. It’s natural and it’s okay. Repeat that message ad nauseum.

Hopefully, with some practice and support, your team can grow comfortable within an iterative space. It’s helped my teams and I know it can help yours!

Blockchain 101: Real-World Uses

Blockchain 101: Real-World Uses

Blockchain 101: Real-World Uses

Written by Sean Kelley-Pegg

You might know Bitcoin as the preferred payment system for ransomware. Or as a volatile investment vehicle (which Warren Buffett won’t touch). You may have read about it as a virtual currency for money laundering or running pyramid schemes. Of course, it’s all those things, but like most things in technology there are two sides to the coin. Focusing on the extreme cases ignores some of the most exciting parts of crypto (for me at least) – the underlying blockchain technology. Blockchain has the potential to impact not just financial but also social systems, and as a technology professional it is important to understand what blockchain is with as little jargon as possible. Crypto land is annoyingly full of acronyms, memes and made-up words, so I hope to give a brief, high-altitude view of the landscape without a lot of clutter. 


So, what is blockchain and why is it important?

A blockchain is a way to share information in such a way that it cannot be changed or deleted. It does this by sharing the data among thousands of participating computers which come to a consensus on “blocks” of new transactions. Anyone can participate by running blockchain software and people doing so are located all over the world. Entities are motivated to not disrupt the system because they can earn money automatically by participating in a well-running system. The decentralized nature of blockchain combined with rewards of participating make it a “highly available” system with powerful hedges against being shut down or fraudulent data being saved into blocks.  

Imagine a spreadsheet of transactions that can have rows added but not modified. The spreadsheet is shared globally and can be read by anyone. Each time a transaction occurs a new row is added recording who sent how much to whom. Because rows cannot be changed there can be no disputes about whether transactions occurred and no possibility of changing information later. Since this spreadsheet records interactions automatically, people can transact directly with each other without involving an institution like a bank, and without needing to know or even trust each other. Like Venmo but without the settlement delays.  

In 2009 Bitcoin was created demonstrating the viability of this concept. However, the real-world uses of Bitcoin were limited. At the time it was difficult to trade dollars for Bitcoin and you couldn’t really buy much with it, except on the black market. Some of the original developers saw promise in the concept and started work on a new blockchain with wider use cases called Ethereum.  

The Ethereum blockchain can store just about any other data along with the transaction. This unlocks many possibilities. For example, ownership of property could be recorded on the blockchain, reducing the need for titles or deeds or other physical documents. Blockchain could store identity information which could be used to reduce online fraud. Forget hacking usernames & passwords –you can’t steal someone’s identity if you don’t have their crypto “keys!” Products could be tracked throughout the supply chain and verified by the manufacturer or purchaser –think organics, temperature-sensitive medications, or how certain raw materials are sourced. A blockchain-integrated voting system could prevent vote tampering. Votes would be permanently recorded, and because the blockchain is public, it would be easier and faster to audit a close election. This in turn could increase confidence in the vote.  

Another Ethereum concept is the “smart contract,” a piece of custom programming that executes along with the transaction to which all parties have agreed. Smart contracts are often compared to vending machines -we put in our money and receive our selection, and the process is completely automated. Smart contracts can be used to initiate any kind of workflow we can think of. For example, escrow money could be released when conditions have been met. Tickets could be issued or traded or automatically refunded in certain cases. A smart contract could be tied to the purchase of digital art so that whenever the work is re-sold a royalty is automatically paid to the original artist. Programmable money!  

Blockchains in businesses

Many large companies are already exploring how their own private blockchains can reduce friction, speed transactions, and increase trust and transparency. IBM has many different implementations of their blockchain for supply chain customers and for those who manage digital assets. Visa is reportedly exploring how the technology could speed up international transactions. Pfizer, Biogen, and other major pharmaceutical companies have formed the Clinical Supply Blockchain Working Group to develop blockchain solutions specific to their market. The Linux Foundation runs Hyperledger Fabric, a framework for building blockchain solutions, and of course Amazon AWS offers a managed blockchain service.  

Those projects often use more centralized corporate blockchains, but there is also a vast network of interesting projects backed by the open-source Ethereum blockchain. I’m excited about IPFS (“Interplanetary File System”), a decentralized way to store encrypted files on the blockchain, making them always available (or one might say censorship-resistant). Another interesting project is “Gitcoin Grants” which uses decentralized voting to distribute crowdsourced funding for blockchain projects. Many of their grants aspire to contribute to the “public good” in some way and support the ideals of shared ownership and collective determination rather than simply making money.  

Benefits of blockchain

The concept of “public good” runs deep in the Ethereum community and many projects display a fresh idealism about creating systems that are fair, do not discriminate, and hedge against some of the more harmful effects of global capitalism.  

For example, blockchain-based voting enables people to organize across national boundaries for a cause they all believe in. Organizations like this are known as Decentralized Autonomous Organizations, or “DAOs,” facilitate human organization at a global scale without needing governments to approve.

Streaming music projects like Audius, and Catalog aim to compete with platforms such as Spotify, while using blockchain automation to put control back in the hands of the artist. The projects aim to connect artists directly with their fans without going through a centralized gatekeeper. In contrast to the tiny royalties paid by the big streaming providers, these projects could enable fans to directly support their favorite artists and enable artists to create unique “editions” of their music with other digital content, increasing engagement.   

Blockchain-based currency can also benefit ordinary people living in volatile economies with runaway inflation. Strange to think of cryptocurrency as a hedge against risk! But in Venezuela, some supermarkets and food chains such as Pizza Hut reportedly accept cryptocurrency as payment, and it’s not unusual for small businesses to periodically convert Bolivars into crypto due to how fast that currency can fluctuate.  

Regardless, today there is at least one small way you can benefit from blockchain now, for free and without risk. On the web these days it seems like the price of admission is to put up with online tracking and ads that follow you throughout your day. We accept that we give away access to our browsing behavior in exchange for free access to sites and services. However, there is another option. The Brave browser blocks online tracking and ads by default, then gives you the option to opt into a discreet ad display in a separate tab. There is no requirement to opt in, but if you do, you earn their blockchain-backed “basic attention token (BAT)”. This is a bit like frequent-flyer points that can be used to tip website creators or be exchanged for gift cards or even Ethereum itself. The Brave browser advertising model flips the current Web 2 model on its head –you are the owner of your data, and you choose when to share it, and can expect compensation for it. 

So, thanks for coming on a flyover tour of blockchain, a technology that will impact all of us in some way in the coming years whether we work in technology or not. Forget about the price and focus on the promise. 

How to be sure your product can go the extra mile

How to be sure your product can go the extra mile

How to be sure your product can go the extra mile

Written by Jared Johnson

I am a product design strategist by trade, but a recreational runner on the side. Lately, I’ve realized that from intentional planning & preparation for a product launch to considering what direction you’re heading for a jog, there are many parallels between delivering digital products and going for a run. Here are a few things to guide your product team along the path of kicking-off a new product, collaborating continuously, and learning from where you’ve been to inform where you go next.  


Preparation is key

Before starting a run, I always spend time preparing my body and mind with stretches and warm-ups. Similarly before you start building a product you take time to prepare.

  • Setting up team working agreements are helpful in aligning how your team members will work together. Same goes with the business partners you collaborate with. Identifying what your organization cares about and circulating that information amongst your team will help keep the team heading in the right direction while executing daily tasks. Using tools like the North Star framework can help with this.  

  • When going out for a jog or building a product, you need to identify the why behind that decision. If an organization is simply looking to make money on a product chances are they won’t stand out from the market competition—or at least not for long. Intentionally thinking about why an organization cares about this product – why it’s worth the time, effort, and energy to create it, and why it matters to those it will serve – will aide in finding valuable motivation that is worth documenting to look back on when the going gets hard. 
  • Asking these types of questions begin to frame-up some other user-centered artifacts and documentation that can help collect feedback and build empathy for those who will be using the product or service once it’s launched. Creating items like an Empathy Map, Customer Journey/Experience Map, or a Service Blueprint can identify ways user needs (wants, feelings, path to completion, etc) overlap with how the business shows-up and can meet that why for the audience the product is intended to serve. 

  • In “The Product Mindset” blog series, Jason Scherschligt—Product Coach and fellow SDG consultant—maintains that getting to know users directly is always time well spent. The more we learn about their known and unknown needs, physical or logistical wants, pain points with other parts of the business, or their own process workflows, the more we’re able to build a product on their behalf. By sheer exposure to this information on a consistent basis, we are able to better retain and understand user needs than any acceptance criteria on a JIRA or Azure ticket could ever deliver in and of itself.

Success isn’t how far you go, but the distance you traveled from where you started.

Steve Prefontaine, American long-distance runner

Roll with the punches

Recently I had the pleasure of running a team race that covered a couple hundred miles of terrain. Although we planned and prepared as individuals, we also came together as a team to agree on how we would work together to cover the miles set before us. During the actual event, rain came, winds blew (so did tires on our pace vehicle), but we worked as a team to accomplish far more than we could as individuals.  


Similarly, when building a digital product or solution, things invariably change. Whether it’s a collective understanding of our users, the priorities of the business unit funding the product, or simply timeline changes outside of the team’s control, there will inevitably be changes the team will need to adapt to and overcome. To deliver a quality product on-time that is within-budget and meets the needs of its users, communication and clarity is crucial between the business itself, experts of the technology, and the end-users. Having collaborative mechanisms for capturing and sharing insights and prioritized problems to-be solved is critical for the delivery team to know not only where they are headed but how to get there. 

As an experience design consultant, I can support this process of documenting user needs, creating resources that help translate abstract ideas into visual or digital experiences, as well as working in tandem with the rest of the product and delivery team—and their leadership. Just like that team race, when we are aligned on the direction we are headed in, know the incremental steps to get there, and lean into our individual expertise & knowledge, we are able to go further faster than if we went it alone.

Champion the wins

When we finish our individual runs or larger team events—like that team race—it’s helpful to think and reflect on how things went. 

        • What decisions did we make that got us here?  
        • How could we do things differently? 
        • Where could we improve next time? 

Similarly, traditional Agile ceremonies like Retrospectives (to assess how the team worked together during the last Sprint) and Reviews (to show & tell what was delivered the previous Sprint) are helpful ways to look backward to help inform what to do next. Finding ways of assessing performance, identifying success (as your team defines it), and celebrating achievements is essential in the process of creating new products and solutions.  

I have learned a lot about myself as a recreational runner, but I was able to cover more ground and grow more as a person anytime I have run as part of a team. Whether you are a team leader, individual contributor, or somewhere in between, I hope you’re able to support the product you’re building with some intentional preparation, rolling with the punches, and championing the wins as they come. That’s how you can be sure your product can go the extra mile.