Category: Prototyping

Categories
Integration Process Prototyping

Single Source of Product Truth

Challenge

Given numerous silos of product information, each with varying degrees of accuracy, evaluate and move towards reliable source-of-truth for driving intra-brand sales.

Action

Phase 1
  • Discovered sister brand developing real-time product DB (in Rails)
  • Evaluated pros and cons of approach with CEO around relying on that DB/dependency
  • Reached out to Prod Mgr for repo access and to facilitate intro to India dev team
  • Dusted off Rails skills / dug into codebase not having any documentation
  • Applied light-touch getting to know key parts of system (e.g. product ingestion, Solr-based search)
  • Worked backwards from UI to determine schema of API
  • Used Postman to prove out ability to programmatically upload products (and introduced the use of Postman Collections for knowledge sharing)

Phase 2
  • After CEO stepped down and interim leadership stepped in, reviewed previous progress, gaining buy-in.
  • Discovered a dust-collecting daily job of 10GB of product data sFTP’d to us.
  • Identified risks of reliance on product repo and charted a parallel path forward.
  • Prototyped Lambda for parsing and processing that data, ingesting into our our product DB.

 

Results

  • Delivered Lambda to process 10GB of product data daily to keep assortment fresh.
Categories
Architecture Backend Chat Cloud demand-side eCommerce Frontend Innovation Prototyping Strategy supply-side

Launched MVP

I was brought on initially part-time into a two-sided marketplace in the holistic services space to assist the team to go from an environment where code wasn’t being shipped to a place that could launch an MVP.

Prior to joining, I commissioned my own Market Landscape (via UpWork) around holistic services potential; one finding: 2015 global revenue = ~$40B

Better Engineering

When I arrived, the POC had been built by an offshore team in WordPress via cPanel and PHPAdmin and transferred from AWS to Digital Ocean. There was no source control. The first thing I did was `git init`.

I spent time attempting to decompose the production instance into a Docker container (of WordPress and MySQL.) I learned how tricky it is when an application is not already 12-factored to spin-up an alternative instance having functional parity. In case you didn’t know, much of the application state of a WordPress site is maintained as JSON config blobs IN THE DATABASE.

Seeing opportunity to prioritize feature creation (in support of product-market fit) in lieu of operational excellence, I put the Docker initiative on hold and spun up dev and staging instances using cPanel and PHPMyAdmin, simply copying the prod DB.

dev instance after trying to decouple

CaaS : Chatroom as a Service

First Iteration

My initial task was to integrate a chat UX with a broadcast streaming experience being built out and powered by Wowza. I settled on Converse.js and ejabberd given decent documentation, an acceptable UX, and (what seemed to be) easy integration; delivering the following POC

chat, working

Next Iteration

With the web server running under CentOS on one Droplet, I had thought it smart to run ejabberd on a separate instance, installing v14 on an Ubuntu Droplet. I ran into issues opening port 5281 from the CentOS VPS to Ubuntu so I doubled-back on my strategy, opting to co-host the daemons on one Droplet (CentOS.) I then ran into package manager issues and wound up having to build and install ejabberd 18 from scratch while upgrading OTP to v20.

While this was happening, the junior engineer was working to get the Wowza live-broadcast video solution working and time wasn’t on our side to get the MVP launched.

(Additionally, at one point, I looked at using the YouTube/Hangout API didn’t find support for our use case.)

Attempt to leverage YouTube/Hangouts

Once I got ejabberd 18 built, installed, and running, we started experiencing timeout issues; manifesting in FE with a spinner that spun for 1.5 mins before the user was finally able to get into the chatroom. I dove into the ejabberd code, and realized that there was something blocking going on server-side. I never did figure out what was happening, but about that same time I realized that the junior engineer had integrated Twilio Video for the 1:1 experience and Wowza Streaming for the 1:many broadcast experience.

Seeing opportunity to reduce waste and consolidate coding paradigms, I researched Twilio Video and realized that we could, for the MVP, likely replace the Wowza experience for both of the 1:1 and 1:many experiences WHILE ALSO leveraging Twilio Chat to replace Converse.js/ejabberd.

Twilio Video, 1:many POC

Next Iteration

I found and customized React Programmable Chat

Twilio Chat, POC

The next step was to integrate with Wowza.

Wowza UX, now w/Twilio Chat

As their were some production issues with the Wowza implementation, I forged ahead creating an alternative Twilio Video React component using React Scripts.

1:1 UX, Twilio Video Chat (desktop and mobile)

At soft (internal) launch, I posited the Twilio solution and the other team members were delighted.

Though the Twilio Video quickstart project was useful, I ran into challenges around the video codecs (VP8 and H.264) between Chrome and Safari, namely getting desktop and mobile video interaction to work as expected. Digging around produced Github links helping lead to resolution (e.g. simply switching to H.264 to ensure cross-browser support.)

On 4/6/18, we had our first successful supply-side (1:many) broadcast, powered by Twilio Video and Chat.

MVP

After helping the team achieve MVP launch and when funding could not be raised in a timely fashion, I moved on.

Results

  • Swooped in when feature-delivery was woefully behind, built out (desktop/mobile) UX, and launched MVP to paying customers.
Categories
eCommerce Prototyping

Centralized to Decentralized Marketplace

Bluxome Labs : 3/18-4/18)

Challenge

Re-conceptualize centralized marketplace idea around leveraging Blockchain.

Action

Going into Q1/18 after the mania of 2017 ICOs, I assisted the CEO to re-conceptualize the centralized marketplace idea around leveraging Blockchain. I dove into the Blockchain ecosystem, prototyped around Origin Protocol, and crafted the initial beginnings of a White Paper.

As part of that process, I explored options leveraging Truffle…

POC (derivative of Truffle Petstore DApp)

… as well as Origin Protocol.

POC (derivative of Origin Protocol DApp)

As the market cooled, we slowed down towards project planning a gradual transition to a decentralized paradigm.

Result

Contributed to Origin Protocol.

Categories
eCommerce Growth Leadership Prototyping supply-side

Beat Company Plan

(The RealReal : 1/17-6/17)

In January, peers in different areas of the company came together in a cross-functional guild with the goal to beat company plan around yearly supply-side user acquisition. Over the following months, we ideated and executed on a few ideas to make that happen.

Where I saw opportunity to realize the most gains for the least amount of (engineering) effort, I acted as Senior Engineering Representative and spoke to the likely costs of implementation, overseeing the ideas we as a guild prioritized.

Re-consign

To realize an idea around “re-consigning” – that is, enabling demand-side to re-sell an item they purchased from supply-side, I threw-together a “reconsign” link with an Javascript alert and beaconing usage via Segment, worked with PROD and DSGN to flesh out the feature in-full, and then managed a remote team to to get the feature (fully-baked) into production.

Friendbuy

Long championed by the CFO, and by consensus of the guild, we scoped out and delivered an integration with Friendbuy; which wound up being beneficial for user acqusition on both sides of the marketplace.

Funnel Optimization

The guild sanctioned a prioritized idea around optimizing the supply-side user funnel. DSGN built out wireframes and I managed the team to realized the new acquisition funnel in Phoenix.

Results

  • Led best 2017 revenue-gen (adding $3M to the bottom-line) and best 2017 lead-gen features (boosting leads by 50%.)
Categories
Innovation Leadership Process Prototyping SOA supply-side

Phoenix Homepage POC

(The RealReal : 2/17-3/17)

Early in 2017, a Tiger Team formed of me, a Lead ENGR, the CTO, the VP PROD, and a PM.

The CTO and VP PROD had an idea to empower Merchandising and Marketing to further drive content/conversions from the Homepage. While they previously had some power to manage that content through an admin interface with a limited schema, the idea was to give them even more creative expression, allowing them free-reign over their HTML.

A few weeks into the project, the Lead ENGR, who had been tasked with building out the intial POC, left (leaving us in a lurch.) Under pressure, I still delivered basic CMS functionality via Rails and demo’d same to the C-suite.

Shortly thereafter, when requirements radically changed and the mandate from the CTO was suddenly to move towards a WYSIWIG experience through a 3rd party Content-as-a-Service provider as rendered via Phoenix, while moving away from a lazy-load landing page to a 3×3 grid, I built out a simple placeholder homepage in Elixir and then evaluated and prototyped against several CaaS vendors (e.g. Prismic, Kentico Cloud, Contentful.)

When the CTO settled upon Prismic for us to move forward with, I conceived the project plan for engineers to carry the effort forward while also developing the initial migration plan for porting route-by-route from Rails to Phoenix.

Results

  • Built MVP of company’s Rails-to-Phoenix migration.
Categories
Architecture Prototyping supply-side

Not Ready for React

(The RealReal : 1/17-2/17)

When I joined, it was with the understanding that as the company was growing, we would need to be splitting out the codebase into a more service-oriented architecture.

In late Q1/17, seeing an opportuntiy to leverage React components to both DRY up and reuse functionality and in a bid to further decoupling frontend and backend, I tasked the remote Russian team with the introduction of React around signup functionality.

When the project was almost complete, an engineering executive required that we pull out React and implement the functionality in a more vanilla way, citing that “any changes that engineering [made] causing the business to potentially miss its numbers would be bad.”

Results

  • Explored (but had to abandon) use of React at TRR.
Categories
demand-side eCommerce Frontend Innovation OOJS Process Prototyping

Better NUX

(Bluxome Labs : 6/16-6/16)

Towards improving the New User Experience, Design came up with the idea to use Callouts around page elements whose affordance wasn’t intuitive.

Given the mockup, I set about implementing it pixel-perfectly.

For the first pass, I simply crafted the markup based on Bootstrap’s Alert and hid it by default, revealing it with JS if logic was met.

Then, realizing that the Bootstrap Alert wasn’t sufficient for Design’s needs and that the Bootstrap Popover was, as well as that there would be opportunity to re-use the code elsewhere in the platform, I created a JS Class for the NUX (a.k.a. “Callout”) and subclassed (example) accordingly, modifying the markup accordingly.

Results

  • Established team habit around refactoring and improving OOJS.
Categories
Frontend Prototyping supply-side

NUX Refresh, Again

Bluxome Labs : 5/16-5/16)

The NUX for the people doing work on the CrowdFlower platform has been around for two years.

Time for a refresh! Given the following from Design

… I set about improving the NUX.

First, I could see the difference in the pre- and post- and decided to remove the dependency on Guiders, a lib that has long served CrowdFlower well. Then, given the design, I saw we could realize the implementation quickly with a Twitter Bootstrap Modal. Going a step further, I also realized it would be the perfect opportunity to introduce React (and even React-Bootstrap) on a small scale in a Rails app where it did not yet exist.

After several copy changes, this was the final Deliverable

(specs were not unfortunately not created in conjunction with the delivered product given the scope they would have added to the original ticket.)

Results

  • Deprecated legacy 3rd party JS lib usage (Guiders) in favor of re-imagined NUX with React component.
Categories
Frontend Innovation Prototyping supply-side

Data ETL UI

(Bluxome Labs : 2/16-2/16)

Given only the following mockup from Design (created using InVision)

I did research until I found this.

I knew there would be a fair deal of work to do to re-purpose the idea to realize what Design had proposed so I started out small in my iterations.

First, I tried to standup the simplest POC using jQuery Draggable that I could in a single, local page.

Then, I added Bootstrap (the styling paradigm of the eventual target codebase) and continued to refine interactions

To get Product and Design’s feedback, I deployed the protoype on Heroku.

I was getting close to integration and that would eventually prove the most challenging (given pre-existing styling interactions and positioning.)

I incorporated my work into the main codebase and iterated on styling and interaction from there. Also, I created a CoffeeScript spec for covering the main features.

Here’s the final product

Results

  • Re-purposed an existing drag/drop example using jQuery Draggable in order to facilitate data management.
Categories
Architecture demand-side Distributed Teams eCommerce Frontend Full-Stack Management Process Prototyping supply-side

Styleguide

(CrowdFlower : 8/15-10/15)

In late August 2015, given previous successes in the year, I was tapped to lead the engineering team for delvering a visual identiy refresh (in conjunction with conference-ready AI deliverable) by early October.

Week 1

  • took Bootstrap 3/Flat UI/custom styling from Designer and created a static page as ‘gold standard’ for other engineers to reference
  • identified priority routes on which the new design would need to be rolled out
reference page

Week 2

  • created a new layout for and and began rolling out new design on the Rails app
  • drafted a plan for updating the Merb app seamlessly
  • began to onboard other engineers

Weeks 3-5

  • prototyped and tested the idea for asset precompiling in the Rails app and replacing the base assets of the Merb app
  • continued polishing
  • guided other engineers on implementation
  • continued polishing

Week 6

  • coordinated bug-free deploy in conjunction with Marketing (who was working for similarly refreshing the third-party-hosted home page)

Results

  • Organized work of four engineers (two local incl. CTO, two remote) as Tech Lead while planning (and tracking against) engineering sprints and deliverables over two months.