surrounded by objects

At this particular point in our history, many of the big, shared societal problems we face feel unsolvable at times. The combination of their scale, complexity and sheer sense of abstraction have led to a whole host of thorny problems. That said, I have hope because of our collective ability to use technology to better understand the abstraction I mentioned.

What do I mean by abstraction? Here's a simple example. Take a look at a dollar bill that you have in your pocket right now (hopefully you have at least one. And if you're reading this from outside of the US, please feel free to substitute a euro, baht, dong, renminbi, etc). When you look at it, what do you see it as? You may think about the value, and that value in relation to other values ('It's only a dollar. I have millions, therefore it's not much,' or 'Wow! A dollar! I just sold a kidney for a bologna sandwich … I better hang onto this.') Or you may associate it with the things you can purchase for that amount ('One dollar equals four Slugworth Sizzlers at the penny candy store on the corner …') In reality, it's only a hard-to-counterfeit piece of paper, which is an abstracted symbol for the value we've been conditioned to place upon it.

So what does this have to do with anything that I blog about? This: Products are abstractions. Their impacts are also abstracted away. I'm not even speaking about the abstraction of branding, fetishizing a product, or buying a product to fill a psychological hole, all of which pile on even more layers. Even if we just consider the material content, physical construction, manufacturing process, and the use and disposal of a product, it's easy to see that those things are buried so deeply within that product that they become distant and unknowable. If some things are so foreign and obscured as to become hidden from view or completely incomprehensible, what chance do we have to change them for the better?

Yet there is hope … The same technology that has increased this distance (between the 'true state' of a thing and our actual understanding of it), has also given us the ability to understand each of the various phases that layer upon one another to create this obfuscation. The camera on our mobile phone and social media gives us the ability to create a testimony anywhere anytime. ERP systems allow greater controls to be put into place related to purchasing practices (assuming those tools are configured to that end). Enterprise SaaS workflow tools allow brands at one end of the supply chain to gain more visibility into materials and supplier sites. Smart sensors are getting cheaper and more ubiquitous, allowing us to gain faster, more accurate measurements of the environmental impact of the ways we live. Creative UI designers are building ways to present oceans of data visually, allowing us to intuitively understand big problems at an emotional level (Don't undervalue that point, as humans make decisions based on emotion). Blockchain technology will eventually be deployed to build auditable chains of custody tracing to trusted sources and safer materials and inputs.

This sense of abstraction may have been baked in by design, through the death of a thousand independent yet individually purposeful cuts. Or it may be an accidental by-product of a global system that sprouted with the speed and inelegance of a kindergarten class fed a steady diet of human growth hormone and gamma rays (and love, of course). In either case, we have the opportunity to be creative and make smart choices to get ahead of the frenzied pace of man-made entropy by enabling more people to make informed decisions by better understanding the cost and value of the big and small choices we make each day (Free bit of consulting - Companies that can reduce the friction of making these choices will win.)

Please note that my earlier use of the Slugworth Sizzler may have violated trademark law, but since Slugworth was lying about his identity to the kids throughout the entirety of Willie Wonka and the Chocolate Factory (and yet is somehow portrayed as honorable at the end), I felt no remorse.

I had a chat with Dr. Prakash Sethi a few weeks ago that I thought I'd share. Dr. Sethi is the Distinguished Professor of Management at the Zicklin School of Business at Baruch College in New York. He is committed to the cause of examining and promoting ethical conduct among multinational corporations, and uncompromising in his critique of corporate practices. In no particular order, here are a few of the topics we covered during our chat:

• Dr. Sethi felt that a lot of energy and resources are wasted as a result of redundant factory audits. Most practitioners in the field won't disagree with that, but many have difficulty getting past antitrust concerns and corporate cultural challenges related to sharing information and coordinating across company lines. That said, Dr. Sethi's point was more tied to incentives. If the right incentives are in place for suppliers, they will invest in improving workplace conditions, reducing the reliance on audits as the primary means to support an entire risk management process. I agree - Audits are one piece of managing workplace risk at a site or in the supply chain. To be specific, an audit is a means of measurement. It is necessary, but alone, it can't replace other essential elements of a well-designed system, such as policies and procedures, communication, skills building or effective governance.
• One way to structure a framework to support supplier incentives is to allow them to choose tiered groupings of suppliers, audit samples of each group accordingly, and incent via higher prices for product coming out of the better tiers. My question to Dr. Prakash was, 'Which companies are good exemplars of having the right supplier incentives to drive positive behavior?' The unfortunate answer was that he wasn't aware of a whole lot of great examples. (I offered Starbucks, which offers higher premiums for coffee beans as part of its CAFE practices program, which he agreed was an exception).
• We spent some time discussing negative externalities, which led to a memorable quote, 'There are a few ways to increase profit. One is to reduce costs. Another is to get another sucker to pay the costs.' (Meaning, negative externalities absorb real unaccounted-for costs that are buried in exploited labor and environmental degradation.)
• We touched on the role of institutional shareholders, and how they should seemingly benefit from pushing for market/regulatory drivers to incent shareholders to hold shares longer than the daily/monthly/quarterly cycle that drives so much short-term decisions by public companies. When asked why more large shareholders aren't pushing for this type of reform, unfortunately, neither of us had an answer.

I think that covers a few of the salient points, but that's based on my recollection (so apologies if I misconstrued any of our chat). Thanks again, Dr. Sethi for the inspired (and inspiring) dialogue!

Over the past few posts, I've written about soliciting feedback from employees in the workplace. I've covered the importance of understanding employee needs in order to accurately assess workplace conditions, the need for empathy, the need for an understanding of workplace power dynamics, and the potential for self-coaching during employee interviews. Now that we've gotten to this point, we'll dive into some unique methods to gather feedback, in particular from employees less likely to openly share honest feedback about an exploitative workplace.

Since employee feedback is essential to an accurate depiction of the workplace, employee interviews are the most important component of a workplace assessment focused on social/labor and H&S risk. When it comes to employee interviews, the traditional assumption is that one-on-one interviews are a more valid means of soliciting feedback from employees than group interviews. The thinking is that employees can speak in confidence during a one-on-one interview, since they are outside of the prying ears of their co-workers who would hear their testimony had they been in a group interview. My last post introduced a participatory approach to gathering employee feedback, which turns that assumption around. The approach assumes that, in most cases, the power imbalance between the auditor and worker is so great that the employee will not frequently disclose the most concerning issues. Therefore, the process is best served by re-balancing the imbalance of power between auditor and worker by increasing the number of workers participating in the discussion.

So how then, you're probably asking, do we address the concern of maintaining anonymity within a group of colleagues? That is remedied by the exercises, which provide a means for employees to communicate concerns in a way that may not directly implicate them in the disclosure. Furthermore, it also allows other workers to support or refute the worker's assertion, which essentially acts to self-correct any false statements. Here are a few examples of some of the exercises:

• Spatial mapping: Take a large sheet of paper, and ask the employees to draw a map of the facility (Or start with the map itself). Then, ask each to circle their most/least favorite locations. That presents the opportunity for the auditor to ask follow-up questions ('I notice everyone put a red circle around the cafeteria … Has anyone ever gotten sick from the food? How long are your breaks?')
• Temporal mapping: Start by asking an employee to draw a twenty-four hour timeline on a large sheet of paper. Give the employees a marker, and ask them to draw or write their activities at particular points in the day. This obviously opens up questions of working hours, breaks, forced labor, and even discrimination ('Why are those workers allowed to leave earlier than those?')

Because the employees are speaking somewhat innocuously about their day or the physical layout of the worksite, it allows them to communicate in an open and honest manner — 'I didn't tell them that the boss makes me work 12 hour days … I just described my day.' That is obviously an over simplification, but the technique makes it apparent when employees try to obscure the truth, especially when multiple employees are being asked to describe a broad system or pattern of events in their own words. When the auditors observe an unusual or muted reaction, they know to dive deeper into investigating that particular area of discussion. The indirect topic and communication through mapping and drawing also act as a sort of sleight of hand — 'No need to look at the children employed at the facility. I'm just asking about the hiring process.' One of the points that has resonated with me was how powerful handing a marker to an employee can be. First, it empowers an employee, as you are giving them control of the dialogue, even if that's not what is explicitly stated. Second, it acts as a karaoke mic, of sorts, and allows less empowered staff the time and space to communicate, even if nothing is openly stated. Third, it also allows the auditor to control the dialogue, by NOT giving the karaoke mic to those most empowered or extroverted. It is a neat little technique in the bags of tricks.

You can practice those techniques on your friends and loved ones while you're waiting for the next post. Enjoy!

My past few blogs have been focused on how to understand the impact of the workplace and employer on an employee. I left off on the topic of power dynamics, in particular, the imbalance of power between the well-intentioned auditor and the employee who finds him/herself in the middle of an interview within a social audit.

Here's what the employee sees:

1. A stranger walks into the workplace.
2. Said stranger speaks with the manager.
3. Stranger approaches employee a short while later, and says they'd like to speak with him/her.
4. Employee says, 'Holy #%&!!' to themselves, and braces for the bad news that is about to ensue.
5. Stranger takes employee to a room to speak in private. Employee still very freaked out.
6. Stranger introduces him/herself, describes the nature of what they are trying to do, and proceeds to ask very detailed questions of a sensitive nature.

As you can see, from the employee's perspective, all of this can be very disconcerting. The auditor is in a significantly higher relational position before they utter a single word, and even the best need to work hard and be very thoughtful in order to gain a toehold of trust. The best take the time to provide a clear and transparent description of their purpose, method, use of information, relationship between client/supplier, and of how they maintain the employee's anonymity. That takes time. The worst dive in with a checklist of Yes/No questions, and with no sense of grace in how to ask the sensitive questions to follow.

In my past life, I had been taught a technique to solicit information from employees in a way that accounts for employees who are more conscious of this huge gap in relational power, and who are less likely to express their needs or to speak on their own behalf. The method grew out of anthropological studies, and was designed to provide a medium for less empowered workers to provide feedback. It follows a few key tenets. First, the interviewer is required to be very aware of the power imbalance, and of the hesitance on the part of some employees to express themselves. Second, the interviewer isn't an interviewer, per se; she is more of a facilitator of a dialogue that should take place between the employees. She is simply there to get the dialogue started, and then ideally recede into the background, only resurfacing to keep the conversation moving forward. Also, she isn't alone. Ideally, she should be paired with a scribe, whose job is to quietly observe, and to write down everything. Both facilitator and scribe aren't trying to interpret what they're observing. That comes later. Another tenet of the technique is to purposely stack the deck against the facilitator, power-wise, by conducting group exercises (note that I didn't refer to them as interviews, but more on that later). The intent is to tilt the power dynamic back in favor of the employee by purposely outnumbering the facilitator. One on one, the auditor is on the high end of the teeter totter. Two on one, and it starts to get more even, but probably still in favor of the auditor. A gang of three or more, and now the auditor's authority grows smaller and smaller, which is good. The less authoritative the auditor is, the more likely the employee feels comfortable and empowered to express themselves. We don't want the auditor to tell the employee what to say. Whether the auditor intends that or not, their mere presence and role can likely cause that to happen. Employees can often self-coach, without their supervisor saying a word. (More on that later.) As stated in earlier posts, this power in numbers is the whole point behind collective bargaining, and why it is so distressing that it is being systematically dismantled in the United States. Another tenet of solicitation of feedback from employees via participatory techniques is that asking employee a direct yes/no question is not highly likely to yield a completely honest answer, especially for those employees who are least empowered and most vulnerable and at risk. The preferred means of soliciting feedback is via open ended questions, or even better, via exercises that are honest in their intent, but less direct in how they gather information, and more likely to preserve the anonymity of the employee.

If you're interested in what these exercises may look like, I suggest that you start warming up so that you don't pull a hamstring, as I'll share more details in my next post.

In my previous post, I began to explore the process of interviewing employees, as part of a workplace assessment. As I wrapped up, I alluded to power dynamics in the workplace, and how important it is for an auditor to have a high degree of sensitivity toward this point. By power dynamics, I'm referring to the significant imbalance of power between various individuals in the workplace — boss/employee, male/female, local/migrant, etc.

The most obvious one is between manager and employee. Even the best managers often don't realize how significant this imbalance is from the perspective of the employee. 'Hi. I'm the guy who can prevent your children from getting fed next week. Do you have any complaints about your job? Good! That's what I thought.' That's why simply saying that one has an open-door policy is actually quite naive, even when that's stated with the best of intentions. The door can be removed from its hinges, but if no one is coming to visit, it's probably because they are scared to death of the boss. And that dynamic is not limited to factory work in the developing world. Even in white collar workplaces in developed nations, the boss possesses implied or explicit power in their relationship with their employee. Of course, the most egregious exploitation of this power imbalance can manifest itself in the worst workplace abuses — verbal/physical/sexual abuse, etc. More frequently, it presents itself in a much more subtle manner, which can lead to forced labor, excessive hours, workers exposed to unsafe working conditions, etc. That unspoken assertion of authority is more often the means — whether purposely or without the manager's knowledge — of putting workers in a position that may be contrary to their needs. That imbalance of power between the employer and an individual employee is the whole point behind collective bargaining, which of course is being gradually dismantled in the US and many parts of the world (which is significant enough of a topic to warrant its own post).

Another power imbalance that many auditors don't account for is the gap between the employee and the auditor themselves. ('Me?! But I'm here to save the world! Who would be afraid of me?')

Sound intriguing? Good. There's your teaser to read the next post. I promise not to make you wait too long.

Few things have the power to affect change or tap into insight like an elegant question. In the criticism I have read about corporate supply chain monitoring programs (e.g. checking supplier factories for labor abuse), I most often hear the phrase 'check-box audit'. I agree … a poorly trained individual asking direct Yes/No questions to employees or management is not likely to uncover subtle, ambiguous, or purposely hidden issues:

• Auditor: 'Are you forced to work?'
  Employee:'If I say Yes, this stranger will tell my boss … Well, I am not physically restrained from leaving, so therefore I am not forced.'
• Auditor: 'Are you sexually harassed in the workplace?'
  Employee: 'That is a weird question, and even if you were savvy enough to ask in a way that didn't make me squirm, I still wouldn't tell you.'
• Auditor: 'Do you employ child labor?'
  Manager: 'Uh, no.'

Ask an obvious question and you'll get an obvious answer. I'm not trying to imply that an auditor should somehow trick an employee or manager into sharing information they otherwise wouldn't. I'm suggesting that the intent and method should be communicated transparently in order to build some level of trust, questions should be open-ended where possible, and that responses that are incomplete, unclear or completely falsefied indicate a topic that requires deeper digging. It's hard to provide a fake answer to the following questions:

• 'Take me through your hiring process from the point you identify the staffing need up until the employee has completed their probationary period.'
• 'What do you think are the greatest areas of risk at this site? What are the most frequent type occurrences? What are the ones with the greatest potential to cause harm? How did you learn about those? How do you mitigate those?'
• 'What do you think that you do well, and where can you improve as it relates to understanding the needs of the workforce?'

How and Why are so much more powerful than What. And then, of course, it is absolutely vital to burrow into ambiguity or discomfort like an underfed tick ( 'Tell me more about that … How exactly do you do that?' ) Of course, don't be a jerk about it, especially with the employee. I'm not suggesting that it's OK to be a jerk with management either, but there's clearly a much different power dynamic.

Speaking of power dynamics in the workplace … I'll cover that in my next post. Until then, steer clear of underfed ticks.

No, this post is not about the Tidy Bowl Man, Mr. Clean, Aunt Jemima, the Kool-Aid Guy that used to bust through walls, or any of the other people ON the packages of products (Although, technically, I don't think that the Kool-Aid guy is a person. Not really sure what his deal is.) The series of posts I'll be sharing over the next few weeks will be focused on the people who have touched those products whose stories aren't so visible.

If we were to crack open any of the products we consume, and somehow follow them backwards through time, we would uncover all of the people involved in their mining, cultivation, processing, assembly and distribution. Most multinational brands have made it fairly standard practice to assess the risk of, and monitor, labor practices throughout their supply chains. In fact, public reporting on this has already been codified into law in California via the California Transparency in Supply Chains Act. The most credible way to assess workplace risk within the supply chain is to actually visit the site to assess their practices and systems; and by far the single most important element of any workplace assessment is speaking with the people that make up that workforce.

All of this sounds well in theory, but in practice, how do you understand what is important to any individual? Within the context of assessing risk in a workplace, how do you understand an individual who you're speaking with for a limited span of time? How do you interpret their perspective in a way that provides insight and a clear depiction of a dynamic workplace? Many people spend a lifetime with loved ones and still never truly understand them, so how is one expected to understand a workplace rife with complexity, pressure and ambiguity … from a brief testimony provided by a complete stranger!

Over the next few posts, I'll share what I've learned about gathering information in the workplace in order to attempt to understand how people are impacted by the employers, products, materials and workplace practices behind the products with which we surround ourselves. I'll caveat this by acknowledging that there are others with much more insight and experience than I have. The following posts will cover a few points that have resonated with me, which I've acquired through a bit of training and direct experience in the field.

Now that I've built up some momentum, I'll leave you in the wake of this preamble, trembling with excitement in anticipation of the next post. (I promise not to keep you waiting too long.)

This is part four of a serialized piece I've been writing about my recent experience building a software platform. I'm hoping it's the last, since the process of writing this blog has become larger and more exhausting than building the platform itself. For this last installment, I'll spend time discussing the piloting we did with clients, and how we prepared them for the launch.

As we built the platform, we knew that there was plenty that we didn't know. Therefore, we worked to engage our current customers to participate in a pilot. We had built our requirements, based on the regulatory requirements and customer feedback up to that point. That's still only a jumping off point, as everything is academic until you're dealing with the real product. I knew that I wouldn't be able to completely remove my own rose-colored contact lenses, so we needed real, living, breathing customers to validate or refute our assumptions, and to provide us feedback to mulch back into the development of the tool.

We reached out to a fairly wide range of customers, but had a fine line to walk — We needed to whip customers into a lathering froth to get them excited enough to participate and invest in our work, but … not too much of a froth, since we were still building the platform, and wanted to deliver anything we promised. For the customers who took that leap of faith, we not only needed to provide a financial incentive to participate, but we needed to extend ourselves to accommodate and appreciate them. That's not just sucking up, because people invest in you, your vision and your ability to get things done, so it's imperative to fulfill the promises you make.

There's also the Goldilocksian task of finding the 'right' pilot participant. They need to be discerning, but not so fussy that they cause all forward motion to come to a halt. They need to be forward-thinking, but not so abstract that they lose touch with the practical application of the tools being built. They need to be comfortable with risk and ambiguity, but not reckless. It is also nice if you are lucky enough to find people who are, well … nice! But not so nice that they are afraid to offer honest feedback. They should be big enough to provide details on a large-scale process from the customer's perspective, but not so big that you run the risk of choking on scale (or alienating a potential customer that would have been fine with a fully-baked solution). They should ask for features and push you to improve, but understand where standardization is in their best interest ('Have it your way' versus 'Two all-beef patties, special sauce, pickles, onions, lettuce, cheese on a sesame seed bun'). I was lucky enough to find a group of smart and honest folks willing to participate who moved the project forward considerably (Thank you, in case you're reading this!)

When you've found your date for the prom, stick to the basic Project Management 101 stuff. You need to provide structure, as well as clear requirements, goals, roles and responsibilities. When soliciting feedback early in the process, ask open-ended questions — How and Why allow you to understand the world from the customer's perspective, and open up the dialogue to potential paths that you may have not considered. As you proceed later and later in the process, and when asking for feedback related to decisions that need to be made, you will need to start limiting options, or you run the risk of getting bogged down in a quagmire. Where options are required, make it easy to decide — Option A or B (as opposed to 'Here's a tutu and a cassette tape of Better Midler's Wind Beneath My Wings … Now do an interpretive dance of how your business challenge makes you feel.') Like most projects, it won't move forward itself. You are the driver, gently prodding your participants forward. That said, it's important to remember that your precious project probably isn't your customer's primary job in most cases. You've got to make it easy for the customer to participate and offer feedback, but not so much that you're doing their homework for them, and simply reaffirming the things you already believe about your product.

Aside from gathering customer feedback real-time as your product comes to life, you'd probably also like your pilot participant to become a customer using your product and passionately telling his/her friends, family and colleagues about it. Therefore, it's also incumbent on you to launch crisply and on time, and to effectively transition the participant from the pilot to production. Each step of the pilot should be designed to take the participant to the logical conclusion of adopting the product once it is launched. There's a fine line between tactfully and honestly escorting the participant through that process, versus being perceived as tricking your participant into a bait-and-switch and onto a platform that they never actually agreed to adopt. That requires a whole lot of dialogue. The onus is on you to make sure that happens.

In the end, we learned a great deal throughout our pilot, gathered feedback that improved the product, and successfully transitioned our participants onto the production platform.

And that, ladies and gentlemen, is (hopefully) the last installment of this series of blogs. I also said that after Rocky, Godfather II, Grease, and Blues Brothers (presented in descending order of quality of their sequels), and that didn't get me much.

PS … If you felt the same flush of pride that I did at my having coined a new word, (Goldilocksian), take note that Google was nice enough to inform me that I was actually the 6,331st person to use that word online.

I've been writing a serialized piece about my recent experience building a software platform. Unless you're one of the two people who have read the last two posts on this topic meticulously, I'll give you a quick recap on how we've gotten to this point (BTW — Thank you to both my mother and my stalker for being both dedicated and thoughtful readers.)

We started with a customer need, which we needed to validate and quantify through building the business case — Here's why you want to fund this project. Then we moved onto the actual design and build, which was a self-reflexive process where we tried to stay open-minded enough to learn and accept what we didn't know, yet disciplined enough to maintain some sort of boundary around shipping product. Lots of fun in both cases (That wasn't sarcastic — It really was fun!)

For this installment, I thought I'd share some details on how we determined pricing. Let's just say that the process didn't unfold in a completely controlled or scripted manner. In fact, if you happened to be a fly on the wall, besides a general sense of low self-worth, you may find yourself asking whether the product manager was taking medication to treat symptoms of schizophrenia (Full disclosure — I was the product manager). If you have more of an … uh, adventurous mindset, you may appreciate the journey we took to get from there to here. Look, when it comes to establishing pricing, it's a bit of a crapshoot, no matter what any MBA or actuary claims. We came in with a fair amount of experience with platform pricing and price models for services relative to buyer/supplier relationships up and down the supply chain. Initially, we had some folks pressed to make budget pushing to charge large upfront costs to the demand drivers furthest downstream in the supply chain (e.g. retailer, OEM, etc). We ended up not going in that direction, in part because I knew how cheap customers can be (No offense to anyone who is considering giving me cash for any sort of work I'm being considered for). In the model of supply chain risk services, it's often the demand driver — retailer, brand, OEM, etc. — that determines success or failure. I was concerned that we'd never get out of the gates, because we would have created a fairly big reason for a customer to say no. I had a feeling that we'd need to adopt a model I'd been familiar with in my former life in supply chain audits, which was to spread the costs across the many interdependent parties in the supply chain (aka — Charge a lot of suppliers a little, as opposed to charging the end brand/retailer a lot.) In the end, suppliers will find a way to include the fees in their cost of goods, so in the end, you and I are paying for it one way or the other (which can also be said for the many negative social/environmental externalities that are a result of our modern manufacturing system).

Our second option was to look at charging by product (still spreading out fees across multiple suppliers). That was the model of the platform we'd extended, so that felt like a decent approach. We were informed otherwise by a prospect who was kind enough to tell us that once apples and oranges were tallied up, our pricing was way out of whack. Time to go back to the drawing board. We looked at the marketplace again, and felt that it had already tacitly settled on subscription pricing of various flavors within a range. (By the way — I don't really like referring to specific people or organizations as an amorphous blob called the market, but … well, I guess that I just did.). That said, we needed to be honest with ourselves, and be flexible enough to change where it made sense (without being a completely boneless lump).

The turning point in pricing came when a colleague was astute enough to ask the question — Who actually gets value out of using the system? It forced us to think through the people involved, their motivations and incentives, and the dynamics of the various relationships involved. As I alluded to before, traditional service/price models in the space were designed around providing professional/technology services to the retail/OEM demand-drivers, which were actually sponsored by their suppliers. This contradicted our notion of 'Who feels like they're getting value from this?' Suppliers usually didn't feel like they were getting value out of tests and audits forced upon them that often revealed that their products or workplaces didn't meet spec.

That paradox forced us to design value for the supplier into the product. We knew what the value was for the OEM/retailer — industrial-scale gathering, interpreting and reporting of large, complex datasets. We assumed that the end-customer would value that enough to pay something. That said, we knew that we'd never get out of the blocks if it were price prohibitive to those demand drivers. So how do we design something that the supply chain would love to pay us for?

When we looked at what the suppliers' role within the process and what they valued, we settled on their ability to share information with multiple customers. There is way too much redundancy in risk management services and supply chain technology. You'll hear suppliers speak of X fatigue (Fill in the blank — audit fatigue, survey fatigue, platform fatigue, etc). We leveraged the legacy platform's ability to share information as a means to mitigate X fatigue, which we hoped would be appealing enough for suppliers to love to pay us. (OK. Maybe we should start modestly with the goal of suppliers simply tolerating paying us.)

With all of that said, we turned this thing over a few times, and when we discovered that we'd been forcing a rhombus-shaped block of wood into a hole the shape of a scalene triangle, we changed and then changed again, ultimately settling on a subscription model funded in part by the demand-driver, and in part by their supply chain. We prioritized getting butts in the seats in order to scale. We knew that the more users we had, the more we could build other complimentary services around their current use; and if it was as appealing as we hoped, it would cascade across products and multiple tiers of the supply chain. There's the long and winding road on how we got from there to here. To be continued.

Authors Note: No MBAs or actuaries were harmed in the making of this post.

In my last post, I described the business-side of identifying, quantifying, and vetting an opportunity. Although I'm viewing this from the lens of building a software platform, that process is probably similar for other new products or services. At this point, we're assuming that we've gotten the green light, and that we're good to go to build. So, here are some observations from how we went from nothing to something (or in this case, something to something more, since this was an extension to a platform that already existed).

So, to provide some context, we set about extending a legacy platform to support the gathering of information upstream in the supply chain to identify the source of materials in products that are subject to US conflict minerals reporting requirements. Our story begins with a chicken and/or an egg. The chicken being that we knew that we needed a template of a platform to use to gather feedback from customers on whether the platform fulfilled their needs; and the egg being that we also needed customer feedback in order to build that template platform … so that we had enough of a sketch to gather feedback from customers on whether the platform fulfilled their needs. (If that didn't make sense, you're have proven yourself as a sane and competent adult).

Knowing that we didn't know what we didn't know, we started somewhere. Some of the research we conducted while we built the business case fed into the initial prototype. The constraints around the prototype were: a. It needed to be built fast; b. Since it needed to be built fast, we needed to use the templates at our disposal (a similar information gathering platform); c. Since this wasn't a fully-funded project at the time (as it sort of ran concurrent to some elements of building the case), we had limited developer time at our disposal. d. We realized somewhere in the concurrent process of designing and building the case, that we'd likely be reliant on a public list of known and certified smelters. Note that I'm trying not to get too caught up in the weeds of the details, so pardon me if I'm being coy. If you're actually interested in the arcane details of tracing the source of minerals back to a valid source, check out my recent podcast on Supply Chain Brain titled SEC Conflict Minerals Reporting Progress Report

The template we had at our disposal was a nice piece of software that had the ability to issue notifications via email to request suppliers to submit information via a browser-based platform regarding practices from upstream in the supply chain. We built out an early prototype, which looked strong, since the template with which we started had quite a clean UI. It supported a fairly simple process of sending and collecting surveys via email to all of a company's suppliers. We called a few customers to get their feedback, in order to dig further into the marrow of designing and iterating.

We learned a few things: 1. People don't like to pay for things. (OK. I sort of knew that already). 2. The prototype that we'd built needed to support more complex processes, data and relationships, both laterally and vertically. In other words, in order to comply with the legal requirements, and in order to declare whether a specific product was conflict free, companies would need to understand whether each underlying component was conflict free (That's the lateral part – A product expands laterally to encompass all of the components within it). And in order to determine whether each component was conflict free, the process would need to extend beyond the immediate supplier that produces each of those components, and further upstream to each additional tier in that component's supply chain, and then to each tier beyond that in the upstream supply chain of each underlying component and then each component's component, ad infinitum until we reached a valid source of the materials that were the subject of the law (That's the vertical part, as we'd need to extend the process upstream from party to party to party within a chain of relationships).

That was difficult feedback to hear (and I'm sure it was difficult to read), because I wasn't sure how feasible it was, based on the constraints as I understood them. Imagine being asked to create a tool to allow a customer to efficiently and effectively dig a hole where both the width and depth was somewhere between 1 and n.

That required a deeper dive to rethink our assumptions about the process that needed to be supported, the data that needed to be captured, and how various types of data needed to relate to one another. As we broke this down, we tried to focus on a few things, two of which were:

• Start with the customer's objective and the data that needed to be captured, and build the process around that. That is relevant in this case, because the speed and complexity that companies faced, and the relative dearth of options, led many of the impacted companies to coalesce around a process and a set of platforms that had been designed based on the constraints of a set of questions captured in an industry-standard spreadsheet survey. The survey had been a boon, as it established a standard question set, but I have to imagine that its Founding Fathers (and Mothers!) established it as a starting point, and had never intended it to be robust enough to support the process in the long-term. Many companies simply relied (and currently rely) on the spreadsheet, email, and a whole lot of gumption and elbow grease. Some adopted platforms that simply aped the structure of the spreadsheet. We acknowledged early on that, if we truly wanted to address the feedback we gathered when sharing the prototype, we needed to start from an entirely different place.
• The immediate opportunity was the customer need related to conflict minerals. The real opportunity was the broader need for buyers and suppliers up and down several tiers of any supply chain to exchange information about any area of risk or opportunity - regulatory requirements, sustainability goals, etc. We focused on the framework, and not the specific set of questions. If it wasn't portable, we were painting ourselves into a corner.

The more customers that we spoke with, the more we understood that the biggest challenges weren't in the technology (but there were plenty of those), but in changing behavior. The first and most obvious was the requirement for suppliers, both immediate and multiple tiers upstream, to provide information in order for the entire thing to work. That seems obvious, but there aren't a whole lot of great answers for that. Companies can employ both carrots and sticks to immediate-tier suppliers, but that gets harder as tiers become further removed. The best we could do was to build a compelling tool that each tier would find value in, and would gladly purchase to solve their challenge. The next challenge was not as expected. As mentioned earlier, companies hadn't had many great solutions at their disposal for a challenge as big, complex and unprecedented as the conflict mineral requirements. Many dove in and adopted subpar tools or processes — When you really need a drink, even a Rheingold Extra Extra Light tastes good (well, not really). The problem is that once a flywheel is in motion, it's hard to slow it down and correct its course. I hadn't expected that sort of change. In essence, what was needed was for companies to front-load more data, better data, and data whose relationships were correctly established at the onset. Many who started with vague data, hadn't yet been impacted by the work and pain that they'd deferred, which was inevitably going to surface downstream in their process somewhere. Like Apollo Creed says in Rocky IV, 'Some people's got to learn … the hard way!' (And, as you know, Apollo Creed was sensitive to the subtle irony of uttering that phrase immediately before dying at the hands of Ivan Drago, protrayed by Dolph Lundgren in an Oscar-worthy performance.)

Once we completed the requirements and sketched out some of the design, we felt like we had something pretty good. We also knew, as with any project like this, that we wouldn't nail everything up front. In retrospect, I think that we got about 85% of the way there with the initial design. Beyond that, the team was awesome in suggesting and building the remaining incremental (and sometimes not so incremental) improvements.

That's a lot. I've got a little left, but I'll save that for one more post on this where we'll cover some thoughts on the pilot, the launch, pricing and maybe a few more surprises.

This post was sponsored by Rheingold Extra, Extra Light. When you really need a drink, and you've really got a drinking problem … Reach for a Rheingold Extra, Extra Light!

If you like hearing the sound of my voice as much as I do, you'll love what I'm about to share (Actually, like most people, I really don't like hearing my own voice played back to me. I feel like I sound like a member of the Lollipop Guild stuffing his mouth with wheat paste to sooth a soft palate punctured by a jagged candy cane). Regardless, if you'd like to geek out on the topics of conflict minerals, technology and supply chains, check out the interview I did with the Supply Chain Brain podcast titled SEC Conflict Minerals Reporting Rule: A Progress Report.

Thank you to Rob Bowman at Supply Chain Brain! Enjoy!

Pardon the self-promotion, but I thought I'd share a mention that EBN Online was kind enough to make about the work we've done in launching the conflict minerals platform in their post titled UL Supports OEMs in Conflict Mineral Reporting Efforts.

To reward their kindness, I have pointed the above link to their site, which will significantly improve their search rank, but will also direct my legion of faithful readers to their site. My apologies in advance to EBN for crashing their servers. Sometimes love hurts.

Thanks, EBN!

I'm in the midst of launching a software platform, so I thought I'd share my observations on the experience. Before I begin, I'll start with a few disclaimers:

• This is an extension of a pre-existing platform, so I didn't weave golden threads of code from spinnerets at the base of my spine to create something out of thin air.
• On that note, I was one of many people whose efforts and input fed into the final product. Thank you to those smart, passionate folks. You know who you are.
• This isn't Facebook, Twitter, Salesforce.com or any number of platforms that will have a broad appeal. It's a pretty sophisticated tool that enables buyers and suppliers to exchange information about the source of conflict minerals up and down multiple tiers of a supply chain. Pretty slick, but you won't be getting poked by Aunt Peggy on this (unless, of course, she happens to be a warlord in the Democratic Republic of the Congo. If she is, now you know why she stopped getting invited to Thanksgiving dinners years ago.)
• There are many people who are infinitely more experienced and qualified on the subject of software development, project management, etc. I'm simply sharing my own perspective on what I observed. If you like what you read, share it. If you hate it, repress those feelings into a taut, sour ball and tuck it away in that secret place where you hide all of your negative feelings (I'm not claiming to be qualified to be a therapist, either).

Now that I have set the bar low enough to prevent even the slightest of expectations, I'll share my thoughts on what the process has been like.

When I was first approached, I was asked to assess the market potential and the viability of building/buying/extending a software platform to complement the advisory and audit services my organization had already been delivering to address our customers' needs related to the Dodd-Frank conflict minerals requirements. The software was ultimately designed to facilitate the process of gathering, interpreting and reporting on information about the source of conflict minerals residing in thousands of products, along with their underlying components and sub-components. Think of the laptop, tablet or phone you're reading this on, decompose it into each underlying part, try to figure out which parts contains tantalum, and then try to figure out what hole in the ground the tantalum was pulled from. Try it for a single component in a single product, and it feels impossible. It felt that way to me when we started, but feels a lot more feasible now that we've gotten this far along the path.

In order to understand what was required, and how a software platform would need to be designed to support those needs, I read Dodd-Frank and the OECD framework front to back, attended various webinars, researched competitor services and platforms, interviewed internal and external subject-matter experts, and of course, spoke with lots and lots of customers. I kept asking questions until I was convinced of the opportunity, and then continued to ask more, just in case I had hallucinated some of the discussions. It was driven by regulation, and was unprecedented in the depth it reached upstream in the supply chain; so I felt fairly confident. Great — Let's fund this thing, right?

Well, most credible managers will ask for more details then that before carving off a hunk of their budget. Therefore, even the best opportunity needs to be presented in its most flattering, yet realistic, light and successfully sold to the right internal stakeholders. This is the point where many people start getting uncomfortable, because: a. Even after all of that research, you are still relying on many, many assumptions; b. The fevered dreams inside your head need to be made concrete enough to make sense to someone with little exposure to it, who probably thinks more rationally than you do on the topic; c. Your personal judgment and credibility are intrinsically tied to your recommendation and how you go about presenting it.

The only thing I can say is that you need to do as much research as possible, fairly acknowledge the opportunities and risks, and be transparent about the assumptions that you're making that go into your projections and recommendations. The Powers That Be will poke holes in your numbers and assertions, but that's a good thing. You'll either defend them successfully, or be proven wrong (or be right but unable to successfully defend your stance, or worse — be wrong yet successfully defend your recommendation). Skepticism makes the process and output stronger, and makes you smarter and eventually calloused enough to endure the vile blows and buffets that the world (and/or project) may throw at you.

So you've presented a somewhat convincing description of the opportunity. That's enough to get us funded, right?

Well, there was also the issue of How we should make it happen. Build from scratch? In this case, it was too late to go down that road. Buy? In many cases, it is the right choice. In this case, we felt that the gap between the present and ideal was close enough to extend one of our pre-existing platforms. It was that relatively small gap that was one of the drivers of the opportunity for us, along with the market need. Let's fund this thing, right?

Not so fast, Boy Wonder … Just how needy is this 'market need'? How short is this ' relative short distance'? What are we going to sell, and how much do we keep? Just because there's a market need, and we are in a position to support that need, doesn't mean the financial opportunity is more compelling than others it may be competing for resources with. That's where Literature majors like me squirm. It's also not the most intuitive or fun part of the process for me personally; but it doesn't really matter what I think, does it? It's a necessary part of the process, and brings the pie out of the sky and back down to earth so that it's something that people can actually eat. This train doesn't leave the station until the conductor blows the whistle.

So you do your research, start with some assumptions, put together projections, run them past people whose judgment you trust. Then they tear them apart, you do some more research, revise your projections, run them past a few more people … Shampoo. Rinse. Repeat. Shampoo. Rinse. Repeat.

Eventually, you get close to a number you think may represent reality; but the laws of quantum physics being what they are, there will multiple potential realities, so even if you nailed a reality, it may be the wrong reality that actually comes to fruition. In this particular realm of existence, that is. My point being is that you're fooling yourself if you think you will nail your projection to the penny. Anyone you are pitching to doesn't expect you to nail the number to the nth decimal point. Don't get me wrong. The number is important, and represents your credibility. That said, you need to acknowledge the limitations of making projections, and lay your assumptions out on the table. The Powers That Be will judge the number, but they're also judging the process behind the number. Save your work.

OK. You've got your number. We're ready to fund this thing now, right? Maybe … if you've done your work, pushed through any number of objections, knee-jerk reactions, and personalities, and of course, if you're lucky. Sometimes, you may have perfectly managed everything in your control, but the opportunity is killed because of the broader external winds of change. But in this case, let's say that the heavens shined long enough on this ragged dog to win the opportunity.

Now, we get to dig into a whole other set of challenges related to building the solution. I'll save that for the next post.