What Are The 10 Ways to Evaluate a Market?

  1. Urgency — how badly do people want or need this right now? (Renting an old movie is typically low urgency; seeing a new picture on opening night is high urgency, since it only happens once.)
  2. Market Size — How many people are actively purchasing things like this? (The market for underwater basket weaving courses is very small; the market for cancer cures is massive.)
  3. Pricing Potential — what is the highest average price a purchaser would be willing to spend for a solution? (Lollipops sell for $0.05; aircraft carriers sell for billions.)
  4. Cost of Customer Acquisition — how easy is it to acquire a new customer? On average, how much will it cost to generate a sale, both in money and effort? (Restaurants built on interstate highways spend little to bring in new customers. Government contractors can spend millions landing procurement deals.)
  5. Cost of Value-Delivery — how much would it cost to create and deliver the value offered, both in money and effort? (Delivering files via the Internet is almost free; inventing a product and building a factory costs millions.)
  6. Uniqueness of Offer — how unique is your offer versus competing offerings in the market, and how easy is it for potential competitors to copy you? (There are many hair salons, but very few companies that offer private space travel.)
  7. Speed to Market — how quickly can you create something to sell? (You can offer to mow a neighbor’s lawn in minutes; opening a bank can take years.)
  8. Up-Front Investment — how much will you have to invest before you’re ready to sell? (To be a housekeeper, all you need is a set of inexpensive cleaning products. To mine for gold, you need millions to purchase land and excavating equipment.)
  9. Up-Sell Potential — are there related secondary offers that you could also present to purchasing customers? (Customers who purchase razors need shaving cream and extra blades as well; buy a Frisbee, and you won’t need another unless you lose it.)
  10. Evergreen Potential — once the initial offer has been created, how much additional work will you have to put into it in order to continue selling? (Business consulting requires ongoing work to get paid; a book can be produced once, then sold over and over as-is.)

When you’re done with your assessment, add up the score. If the score is 50 or below, move onto another idea—there are better places to invest your energy and resources. If the score is 75 or above, you have a very promising idea—full speed ahead.

Anything between 50 and 75 has the potential to pay the bills, but won’t be a home run without a huge investment of energy and resources, so plan accordingly.

From: https://personalmba.com/10-ways-to-evaluate-a-market/

Case Study: an Invoice Management System for Creek Enterprise

Creek Enterprise is in construction space: they manage multiple construction projects, and each such project can have hundreds of subcontractors submitting estimates and invoices.

To manage invoices and the work done by the subcontractors, Creek uses “Subcontractor Management Tool”, or SMT. The previous version of it was written 8 years ago, and while robust and reliable, it was getting obsolete and in need of a redesign.

My team was approached to do the redesign and rewrite of the existing tool. We chose a different stack – went from Python and SQL to Ruby and MongoDB. We chose to implement the frontend in jQuery, rather than React for this client. We deployed on CenturyLink cloud using lean custom deploy scripts. AWS S3 was used in this stack for object storage.

The project took several months and was completed successfully. It’s in maintenance mode, and my team does rolling feature augmentation and bug fixes.

Since the SMT is performing well in the company, there are plans to license it out to Creek’s peers and companies that need a similar-functioning tool. The architecture of the tool is modular enough that it will make licensing, and even on-premise installation (for audit and security reasons) a breeze.

Sturfee Build Pipeline


I consulted for Sturfee in 2016.

Sturfee is an engineering-heavy small startup team developing products in AI space. As data scientists and scientists, the team was is knowledgable about AI and ML, however they lack experience in software development, and knowledge of best practices. Sturfee reached out to me to setup process for building their software, managing environments, codebases and versions, and implement an agile development cycle.

The Problem

  • Multiple environments, multiple versions, multiple branches of multiple codebases
  • Microservice architecture necessitates a higher degree of infrastructure management than monolithic applications
  • Junior team members not following naming conventions
  • Hard-coded environmental variable in the codebase

The Stack

  • Angular Frontend
  • Go microservices
  • Node microservices
  • Python microservices
  • All hosted on AWS

The Solution

It was critical to separate configuration from the codebase. I saw that some variables, such as database names and port numbers, were actually hard-coded into production code, sometimes with if-then statements that got clumsy and unmaintainable extremely rapidly. I modularized the configuration, moved it to separate data containers (json files files),  removed these files from code repositories, and started managing these config files with infra orchestration tool (chef).

I introduced naming conventions and semantic versioning. Version number of every codebase became semantic and readable: just by looking at the branch name (correlated to the version), one is able to see what branch is the latest, and belongs to which proposed release. My methodology is losely based on git flow and semver, however see <this-article> for the complete description of git versioning that I recommend.

  • Opscode Chef
  • Jenkins
  • Semantic Versioning
  • Custom build scripts that allow push-button, repeatable & accountable deploy process
  • Branching strategy that involved a stable master branch and rolling release branches, plus feature braches that get merged into release branches (that are tracked by the master branch, which is presumably the latest stable).

See the Sturfee Build Pipeline whitepaper for additional information on this project.

Case Study :: Creek Enterprise

Wasya Co was retained by Creek Enterprise for development of their next-generation Subcontractor Management Tool (SMT).

Creek Enterprise is an engineering and construction services company. They operate nationally, mostly in the Midwest, building infrastructure and providing other engineering services for their clients. They are headquartered in Tecumseh, MI.

Managing subcontractors to do construction is a challenging task. Each site can have dosens of workers, dosens of jobs, numerous equipment to be tracked, materials, and personel to be accounted for. They have used a python-based solution for the last 10 years, which although adequate has become outdated, and in order for the company to maintain its competitive advantages, the decision was made to write a next-generation management tool. Wasya Co was contracted to do the work.

The team was always very agile, small and fast-moving. I acted as the principal full-stack engineer, and Zach was the designer and a business liason. There were two decisionmakers / stakeholders on the project, making business decisions. The project took about a year to compete.

By the end of the work, the new system has been implemented, with a number of features that were missing in the old system. The new system is flexible enough that new feature requests were easily accomodated and implemented. The deployment process was automated, making iterative development possible. Multiple performance metrics and analytics were implemented, giving the business a good view into both performance of the tool, and performance of projects and subcontractors the work of who the tool facilitates.

Currently, the main development is complete and the project is in maintenance mode: security updates, bugfixes, and occasional feature requests are being done.

Innovation vs Invention

Innovation is the process of improving existing processes, tools or products. The result of research and development is hopefully innovation, although it could also be invention. Innovation is discovery and improvement. It is the fuel that drives competitiveness in manufacture, and in other industries. Companies that don’t innovate are subject to falling behind their competitors.

Innovation is a core value of certain advertising agencies, and other digital businesses. An entire value proposition can be constructed from the hope of innovating in a market or industry segment. Innovation often leads to disruption. The result of innovation, sometimes, is the paradigm shift that forces an entire industry adapt to newly found practices.

Invention is the creation of new things, products and services. A new scientific instrument is invented. A process is invented; whereas innovation is hopefully a property of the new product or tool.

Internet was invented. The assembly line, as well as any machine or process, was also invented. All the tools and fruits of the industrial and digital revolutions have been inventions, in the very beginning. Inventing is closely tied with manufacture: an idea is not invented, it is the resulting tool or machine that is invented. Inventing can be a job: design of new things is by definition invention.

The two are similar and related. Innovation often leads to inventions. An invention without innovation is usually less market-competitive than otherwise. They are, however, different concepts. It is possible to invent a machine without being innovative. And if an innovation is not implemented, it can be left without the corresponding inventions.

Tight Feedback Loops as an element of Agile Management

The importance of feedback loops in agile management and development

I deal in technology a lot, so my monologue on the topic is technology-centric.

There are several feedback loops that are worth looking over. (1) The feedback from developer to manager; (2) the feedback from user to developer.

It’s worth noting that the closer/tighter the feedback loop is, the more value it brings. Being able to expose errors and omissions, from user back to the developer who actually fixes the problem – the faster it happens, the less time is wasted, the faster overall development takes place.