Archive for the ‘Uncategorized’ Category

Articles

False assumptions on the minimum viable product

In Architecture,Business,Marketing,Product Development,Uncategorized on September 16, 2010 by petrem66

If you use Geoffrey Moore’s book ‘Crossing the Chasm’ as a general guideline on how to tap into a profitable market niche on the long run, the Lean Startup concept must be strongly refined. True, that the aim is still to lower the waste to the minimum during startup, but one has to admit that conducting market research with screenshots, mockups, or partially working prototypes is also a form of waste. Who is going to take you seriously and allocate precious time with you talking about screenshots?. Friends, colleagues, relatives, people who are not busy running real businesses. I’ve talked to people in my social network and it is hard to convince them to even consider introducing me to really busy people. Do I have a case to push for that? No, not yet. I know that the path to the ‘chasm’ is a different one though

I think that the absolute minimum to get to playing the market fit game is to have a functioning core product which is easy to customize at the front end (that is UI) to allow for testing market hypothesis as they’ll come. Only after that is done I can afford to do proceed with testing – learning – realigning or extending, and when possible get paid for any service I will provide to customers my product will manage to get

What is the functioning core product?

Generally speaking the core product consists of independent functionality, a minimum set of building blocks absolutely needed to use in any ‘solutions’ to solve in the problem domain. In all startups a common building block is the payment functionality. The building blocks must help lower the cost of putting together the minimum viable product so that when testing a market hypothesis you can charge for service should you find a real customer. Only by making a revenue you know for sure that your solution solves a real problem and hope for a solid market traction

If after a long struggle to find customers and problems to solve, you’ve got a customer but cannot charge for your service that’s bad. A business is about selling goods and services, not volunteer work. Signup for membership is also part of the core functionality

In my case, the document engine is also a core building block since my problem domain with www.documentclick.com is all about documents

What core product is not?

Although there are aspects in it that are part of the core functionality, the user interface in general must not be listed for the core product. It will be refined over and over for better SEO, appeal for customers, usability, etc. Adapters to third party platforms (such as integration with salesforce.com, zoho.com, or google apps) may come later as you discover a market niche for them.  SEO is not yet a concern.

Building generic frameworks to assemble building blocks in never a good idea. There are at least a few dozen excellent frameworks out there (including CMS/DMS) that can be ‘customized’ with minimum cost to include your building blocks and specific UI for a minimum viable product

Articles

Customer Development methodology

In Uncategorized on September 9, 2010 by petrem66

It seems to me that Cindy Alvarez has produced an excellent hierarchy for the best method for reaching out for customers when following the Lean Startup methodology. The daily cost for Google AdWords is smaller and broader in reach that getting an introduction with a potential client and conducting an interview

Articles

On Customer Development methodology

In Uncategorized on August 21, 2010 by petrem66

I try to follow this method invented by Steve Blank for startups as closely as I can. It does make sence since it formalizes one rational method of proving the worthiness of a business model before pooring in lots of cash and effort.

Right now,with www.documentclick.com I am in the very early stages of being able to demo it the customers and to try to find early adopters. The key goal at this stage is to find out the best use and market for the capablilities of this grid based application to produce customized documents on the fly. I’ve seen the demand in all the companies I’ve worked at so far. They were very large companies and on the late adopters graph (as per the ‘Crossing the Chasm’ by Geoffrey Moore). Cannot even dream of approaching them yet at this stage. My goal right now is to find and to validate the use of my engine for a more approachable market such as Toronto based small businesses that have an online presence (such as a website).

I have found a very useful, step by step guide for market validation at Ash Maurya’s blog posting. The only disconcert with his posting is that my initial bag contains more then 3 problems that I could start talking about for problem presentation

A down to earth description of the process can be found in the FAQ at the blog of Cindy Valdez

Articles

My experience with oDesk

In Uncategorized on August 9, 2010 by petrem66

I’ve been hiring for small tasks that I can outsource on oDesk. For almost a year now, my goal has been to find reliable pros to work for me on the long run on DocumentClick. To my disappointment, I found none so far, but learn some lessons to remember. I think these I can share on my blog.

1. I’ve learned the hard way not to hire on the hourly pay. Even the most honest developers tend to overestimate their value and charge for work that they think they’ve done. Better set a reasonable fixed-price on work. This way you can ensure that you pay for code delivered

2. Do not assume that even the best coders will be able to guess what you want from them unless you constantly remind them what you need. Sometimes your good English will not help so you need to put up some extra time of yours to come up with samples, test cases and diagrams to be made well understood

3. Do not assume that coders will always act on their accepted contracts. There are cases when people abandon tasks midway without any notification. Make sure that you have a backup plan such as to hire a second or third developer

4. Excellent coders are always busy. They are hard to find, and hard to keep

5. Rating on odesk is sometimes misleading. Make sure that you have a set of quiz questions handy to make sure that who you’re hiring is qualified. This is especially true for WebDesigner most of whom are not hands on with CSS and Javascript

Articles

Tech support issues and the earthquake in Toronto

In Uncategorized on June 23, 2010 by petrem66

It seems to me that today was a bad day. I was in the middle of implementing some code when there was this tremor of 5.5 on the Richter scale here in Toronto. This is not an unique event here since a few weeks back we got shaken again by a smaller earth quake, but it is unusual for this part of the world since we are located quite far from the edge of this continental plate.
The ADSL Business Internet service from Bell is very far from being fast as posted on their site. For the price of Fibe 25 ($56.9 – 25Mbps for download) I am getting a service with fluctuating speed, which goes down to below 1 Mbps for downloads (0.1 Mbps for uploads) during business hours, and climb up to maybe 5 Mbps during evenings and nights. I’ve called them a few times to try to obtain at least a stable 5Mbps for downloads unsuccessfully though. I am shopping around for a better ISP in town.

Articles

Apache FOP

In Open Source,Product Development,Technology,Uncategorized on May 12, 2010 by petrem66

I’ve been using this transformer for many projects so far. It is quite powerful in the way that it can build documents based on a structured definition that’s built according to the XLS_FO schema. The utility of such package is obvious since building dynamic documents is necessary in many B2B or B2C applications, and Apache FOP is good when processing speed and memory footprint are not issues, but it falls short on performance.
The package operates on a four step transformation of the input definition (the XLS_FO document). First, the package loads and configures its main objects, including the renderer, and loads the available fonts into internal objects
Second, the package loads the input constructing a hierarchy based on FONode objects (Root is at the top) using a plain old SAX parser and a custom made Content Handler.
The third step kicks in when on of the page sequence elements in finished building at the end element method call of the Content Handler. The step consists of transforming the FONode based hierarchy into an internal format based on Block and its specialized subclasses. This structure is an abstraction on the layout of the document, a sort of an medium independent view.
Finally during the fourth step, based on the chosen renderer (one has to pass in the mime type of the expected output), the Block based hierarchy is rendered to a final output that can be PDF, PNG, TIFF, JPG, HTML or even RTF.
Based on my experiments with Apache FOP, I am confident that it use 40% of its processing time and cpu on the first step, 30% on the second, and 20% on the third and 10% on the last. What does that mean?. If for a 3 page document the transformer gets it done in 2 sec, one can be sure that it has burned 1.4 sec to prepare and load the XLS_FO, and the rest (0.6 sec) to do the actual job. That’s quite a limitation, and I think it can be done better.
The first think to improve its performance it to rewrite the code pertaining to steps 1 and 2. The challenge is that its not easy to replace the FONode based hierachy with something lighter such as a XmlBeans based

Articles

On unit testing

In Product Development,Uncategorized on April 28, 2010 by petrem66

I think it will take a how lot of time to do proper unit testing. It is like coding twice as much as it should be. The benefit though it is that one can verify a lot faster that modules behave as expected. There are some very good points about unit testing at writing-great-unit-tests-best-and-worst-practises
The big question still remains about how granular the testing should go. There are two main ‘camps’ of unit testing supporters that I know of.
People in the first camp believe that the best results are to be obtained when unit testing at component level, such as at class level. One should not leave out any visible functionality of it, and with the unit test both negative and positive use cases are to be covered. I have an issue with this approach in that with growing code, and an evolving product it is very hard to maintain the integrity of the unit tests. The second camp, align the unit testing to the structure of the application, that is, unit test can follow the lines of delimitation between modules seen as a unit. Remember some design patterns like the session facade, people in the second camp won’t bother testing such a class since it merely pass on requests to other classes. Further, when you use dependency injection with Spring Framework, the module unit testing becomes the only logical choice