Advertisements

Finding a Product That People Will Buy

This, of course, might be my fatal flaw.

The product I’m creating is a competition to the humble Enamel Pin, but better.  Our products are different but in a good way. 20171022112223_235x

They are full color (with minimal limitations on color), scalable from single badge to 1000 badges.  The image to the right is a series resulting from a collaboration with a designer, Alyssa Harris, a young designer from Idaho.  As you can see, they are full colors, random shapes and can look pretty damn cool.  Due to the manufacturing method I’m using, and the back end code that I use for generating the badges, I can scale pretty easily based on fairly simple input.

The closest analogy to this product is the enamel pin.  These are lapel pins that are carved/stamped out of metal and then painted to give the color.  These have been slowly gaining popularity for a year or two. There is a large number of the pins on Aliexpress, and so within the Pin community there is a hell of a lot of Rick and Morty pins going around.  These are exactly the same pins.  Emojis are also extremely popular due to the familiarity and generally free artwork.   There is a growing number of kickstarter campaigns where people crowdsource funds – sometimes thousands of dollars to get the first batch done.  Now there are also a lot of absolutely amazing designers and pin collaborators out there.

Soft enamel pins seem to have stabilized at around $9-12 retail.  So that would tell me that somewhere in the $7-10 range would be reasonable – if the financial side maps up.

So how is Badgly different.

  1. These don’t need to only be pins.  Since they are an unfinished blank when we receive them I’ve settled on pin backs for pins, or magnets.  This allows the same design to be used for Lapel Pins on leather jackets, pinboard pins, hat pins.  The magnet form can be for fridge magnets, cubicle magnets or lockers.  So I’ve got a fairly broad set of applicable options.  On Badgly, the purchase options for all designs is either magnet or pin.  I currently don’t differentiate on price since either one comes down to a few cents.
  2. There is no metal, the badges are made out of sandstone, so they are considerably lighter.  A design for a typical enamel pin will usually have the walls in the design, where the metal prevents colors from mixing.  For the Badgly pins there is no wall, you can have colors right alongside each other without needing any separator.
  3. Since we don’t have a die to cut, a single badge is effectively no more expensive than 100 badges.  For custom designs, this makes the difference between a $15 purchase and a $150 baseline purchase.
  4. Designs are easy.  In the simplest form, it’s an image to simple 2D badge.
  5. 3D. Badgly pins can be 3D, in the simplest form each individual color can be raised or lowered to different heights – providing a very unique experience.
  6. Contoured 3D.  Beyond the straight 2D extrusion, Badgly pins can have any 3D contours you’d like. This is similar to 3D cast pins.  3D cast pins have an entry cost for about $200.

Head over to https://badgly.com/ and tell me what you think.

Advertisements

The Long Slow Path to E-Commerce

I’ve had Badgly open for about 2 months now.  Traffic is slowly building, but as is typical in Shopify stores bootstrapping themselves and coming from nowhere, I haven’t made a sale, yet.  I’m actually completely fine with that for the moment, since it allows me to understand what is going on before I feel I am risking customers.

My understanding of the who e-commerce growth aspect goes something along the lines of…

  1. Have a product that people want to buy
  2. Have a website that organically ranks for people looking to buy.
  3. Invest in social media to grow a following
  4. Invest in advertising to get more people

That, of course, sounds very simple.  Now particularly with drop shipping, there are many thousands of stores that throw a nice face on a product using stock photography, market the hell out of it and as orders come in pass them off to a wholesaler who does shipping and other logistics.  In theory a nice little opportunity for some relatively passive income.

I’m not in it for that.

Based on some experiences previously, I’m creating pins, badges, and magnets using full color 3d printing, finishing by hand.  These are more or less in direct competition with enamel pins, but I’ll get onto that later.  So let’s pull apart my assumptions above and see where the lead.

So next post… the product…

This is a post that is part of me documenting my experience building the Badgly store.  All the articles are grouped together under the Badgly Category.

Learnings from an Online Store

I’ve recently opened an online store for Pins, Badges, and Magnets using 3D Printing technology.  The store is called Badgly and is at https://badgly.com/ go there, the link to the left has a 10% off discount applied. They are mostly equivalent to Enamel Pins, but don’t have the high upfront costs of creating the die and manufacturing them.

As part of this journey, I’ll be documenting my experiences with Shopify, Adwords and building an online presence.  I’m not going to guarantee that my assumptions will be 100% correct, but I hope that my experiences will help others going through the same process.

All the postings will be under the Badgly category.  Feel free to post comments, corrections or insights below.  Some of these posts will be cross-posted to Badgly, depending on the contents – on use-cases.org, I’ll be a lot more open about the frustrations, machinations, and pain that goes into building an online presence.

Meltdown and Spectre Computer Vulnerability Cubicle Magnets

When something bad happens, like Meltdown or Spectre, or Heartbleed, your engineers end up having late nights,  grueling daily update meetings.  At the end of the day when the dust settles, we don’t get a Service Ribbon that shows your involvement in those days of battle.

With the security industry creating well-recognized brands and logos some of the bigger vulnerabilities, we might have those opportunities to make sure those that join the firefight get the tech equivalent to the service ribbon.

At Badgly, we’ve created some cubicle magnets that allow for a commemoration of those days when you lots lunches, nights and weekends to solve some of your companies biggest and burning issues.  We’ve got a set of Vulnerability badges for Meltdown, Spectre, and Heartbleed.  We’ll update this post with images when they get back from the printers.  Some sample renderings are below.

For geekiness points, all the vulnerability badges will be golden-ratio rectangles.  Is there a vulnerability that you’d like to see memorialized?  Post comments below.

 

 

The Evil Genius of the Amazon Six Page Narrative

One of the leadership tools that Amazon uses internally is the Six Page Narrative.  This is where a decision that needs to be made is presented as a narrative document, restricted to six pages, with appendixes.  The outcome of the narrative is a go/no-go on the subject.  The meetings that discuss the narratives are typically 15 minutes of silent reading/note taking followed by 30-45 minutes of deep dive questions and clarifications.  The best possible outcome is 5-10 minutes of discussion and then a “Good narrative, I agree, go do it!”.  A bad outcome is “I now have more questions than I started with, let’s stop the meeting now and meet again in two weeks.

The narrative is actually fairly evil in its construction. The six pages and the structure of the document itself are ultimately fairly arbitrary.  It is the forced revision/improvement/validation that is forced to fit into six pages that is critical.  As many a good orator has mentioned conveying detailed content concisely takes longer to prepare than long form.

The six pages is a hard limit for the narrative (and no, you should drop to 6 point font with 0.25 inch margins, that defeats the point).  By forcing a limited set of pages it forces the author (or authors) to go through numerous drafts to reshape the document, polishing it by ejecting, rewriting abstracting and summarizing as you go along.   This forces a reasonable taxonomy and structure of information within the subsections and a good ordering of information. This repeated revision to fit takes the mental work that the reader must undertake to correlate and rationalize the information.  If the document takes the reader is taken through a clear path where the questions are almost immediately answered, it shows clarity of thought and understanding, increasing confidence in the author far more than a set of bullet points on a powerpoint.

One final part that is overlooked in the six-page structure is the appendixes. The appendixes carry the data, the validation, the information that feeds into the narrative that isn’t needed to support the narrative, but is needed for completeness and cross-reference.  You can say “our data supports this information as follows”, the appendix allows the reader to dive deeper into the data to ensure that they would draw the same conclusion, but assuming that the data presented in the narrative can be taken as interpreted correctly, then the narrative can still hold it’s own.

This approach is common when needing to write a concise 1 or 2 paragraph email. You write what you want, re-work, re-work, re-work.  Placing a sometimes arbitrary boundary on an output forces a deeper consideration than would otherwise be delivered.

Other Amazonian documents have a similar templated structure that to some extent is inviolable structure.  The 1 pager, the working back document, the root cause analysis, all structured to force the presenter to think, structure and organize their thoughts.  For communicating business information, I don’t think I’ve seen it necessary to present a Powerpoint for quite some time.

The narrative form still has some risks.  To stick with the narrative form, authors are sometimes tempted to inline what is better communicated with tables a) option a – 15, b) option y – 25, c) option z – 10.  By its nature, this information is tabular in form.  A small structured table can carry a lot more information and take considerable cognitive load away from a reader.  The narrative author must balance the use of prose with other information dense methods of presenting information.

What other documents does your organization use to communicate ideas?  Are the powerpoint templates still the ruler of your domain?


This is a Quora crosspost from this answer.  I’m reposting my popular answers here for posterity.  Obviously in a different context it has been modified slightly primarily putting context inline

Towards a Skate-Dad (Day 1)

So this Christmas, we bought our 10-year-old a skateboard.  As part of ensuring there is a bit of extra commitment, I’m joining them in learning to skate.  So let’s put it into context here…  43 years old, 225 lbs, mostly sedentary lifestyle tech geek…  so that probably paints the picture.

So why am I doing learning to skateboard?  The first part is to do the whole role model thing.  I have reasonably high expectations for my kids to be resilient through adversity, to put in the time to practice to get good at things.  If I expect them to get up after hitting the pavement, I can expect them to…  They are a hell of a lot less fragile than I am and should be able to get up and move after a fall that would wipe me out.  I’m also doing this as part of a general effort to get fit and ensure that can learn new physical skills.

What’s my end point?  Realistically, I currently have little interest in doing tricks, I’ll probably declare personal victory when I can push, tic-tac and pump on a half pipe and turn…  We’ll see how much further it goes from there.

This part of this blog will give periodic updates on my quest to get to the endpoint.   Today is day 1…  My kit is an 8.5″ board, 54mm wheels, from the local Skateworks shop.  I’m a bit of an analytical geek, so I’ll also be writing up some of my thoughts, most likely ill-founded, for others to pick on.

So Day 1…  Practicing pushing, very simple tic-tacs… Becoming kind of comfortable.  Of course, day 1 something has to happen.  If my memory serves me right, my front foot wasn’t in the right spot, I tried to do a push, and it all went downhill from there.  I ended up rolling my left ankle and landing on my right hip.  No bruising on the hip, but the ankle is now strapped.   We’ll see how the healing goes, but I’m eager to help the kids out on the park again before the new year break finishes.

Fortunately, or maybe not so, fortunately, it took a few hours before the pain from the rolled ankle to kick in, so I got about another hour of practice at the skatepark.

ng-Whatever

We’ve all done it, sat around a table dissing the previous generation of our product.  The previous set of engineers had no idea, made some stupid fundamental mistakes that we obviously wouldn’t have made.  They suck, we’re awesome.  You know what, in 3 or 5 years time, the next generation of stewards of the system you are creating or replacing now will be saying the same thing – of you are your awesome system that you are slaving over now.

So what changes?  Is the previous generation always wrong?  Are they always buffoons who had no idea about how to write software.  Unlikely.  They were just like you at a different time, with a different set of contexts and a different set of immediate requirements and priorities.

Understanding Context

The context that a system is created is the first critical ingredient for a system. Look to understand the priorities, the tradeoffs and the decisions that had to be made when the system was first created.  Were there constraints that you no longer have in place, were they restricted by infrastructure, memory, performance?  Were there other criteria that were driving success at that stage, was it ship the product, manage technical debt or were there gaps in the organization that were being made up for?  What was the preferred type of system back then?

Understanding these items allow you to empathize with system creator and understand some of the shortcuts they may have made.  Most engineers will attempt to do their best based on their understanding of the requirements, their competing priorities and their understanding of the best systems that can be implemented in the time given.  Almost every one of these constraints forces some level of shortcut to be taken in the delivering of a system.

Seek first to understand the context before making the decision that the previous team made mistakes.  When you hear yourself making comments about a previous team, a peer team or other group not doing things in the way that you would like to see it, look for the possible reasons.  I’ve seen junior teams making rookie mistakes, teams focused on backend architectures making front-end mistakes, device teams making simple mistakes in back-end systems.   In each of these contexts, it is fairly obvious why the mistakes would be made.  Usually, it will be within your power to identify the shortcoming, determine a possible root cause by understanding the context and shore up the effort or the team to help smooth things over and result in a better outcome.

Constraining Your ng-Whatever

When faced with frustration on a previous system, consider carefully a full re-write into a ng-whatever system, or incremental changes with some fundamental breakpoints that evolve, refactor and replace parts of the system.

It is almost guaranteed that the moment a system gets a “ng-Whatever” moniker attached to it, it becomes a panacea for all things wrong with the old system and begins to accrete not only the glorious fixes for the old system, it will also pick up a persona of its own.   This persona will appear as “When we get the ng-whatever done, we won’t have this problem..”.

These oversized expectations begin to add more and more implicit requirements to the system.  Very few of these will be expectations will be actually fulfilled, leaving a perception of a less valuable ng-Whatever.

Common Defect Density

I’m going to come out and say that most engineering teams, no matter how much of a “Illusory Superiority” bias they may have are going to be at best incrementally better than the previous team.  With that said, their likelihood to have defects in their requirements, design or implementation will be more or less even (depending on how the software is being written this time around).

The impact will typically be that the business will be trading a piece of potentially battle hardened software with known intractable deficiences, with a new piece of software that will both have bugs that will be only be ironed out in the face of production.  Even worse, there will always be a set of intractable deficiencies that are now unknown – only to be discovered when the new software is in production.

When the original system was created, it is highly unlikely that the engineering team baked in a set of annoying deficiencies.  Likewise, the new system will, to the best of your teams understanding,  not baking any deficiencies into the system.  You need to make a conscious decision to take the risk that the new issues will be less painful than the old issues are.  If you can’t make that call, then sometimes refactoring and re-working parts of the system might be a better solution.

 

What have your experiences been with ng-Whatevers?  Have you found that your team can reliably replace an older system with a new system, and see that in a few years time the new system is held with a higher level of esteem than the original system?  Follow this blog for more posts, or post comments below on this topic.

 

%d bloggers like this: