http://idcee.org/p/giora-kaplan/
Gig is a web visionary with extensive experience in product management and technological invention. Together with his co-founders, Gig has managed to revolutionize the web by developing the technology allowing everyone to easily create a professional and striking web presence.
Gig has been involved in web publishing since the early 90s. His personal vision is to make web technologies accessible to all, and this has made him instrumental in shaping Wix’ platform. He is bored by and hates “me too” and copy-cat ideas.
Gig’s experience focuses in the consumer internet and digital publishing fields, most notable of which is Optimedia Ltd which provides cutting edge internet & digital publishing technology to global publishing houses. In all his companies, one of Gig’s top priorities is the work environment and it’s important for him to provide a fun, creative and inspiring place to work.
On a day off you can catch him scuba diving, surfing or cooking.
Pic's are here: http://www.flickr.com/photos/idcee/sets/
More @ http://idcee.org
Follow us on:
YouTube: http://www.youtube.com/user/OfficialIDCEEChannel
Facebook: https://www.facebook.com/IDCEE
Linkedin: http://www.linkedin.com/groups/IDCEE-3940138
Twitter: https://twitter.com/idcee_eu
Google+: http://gplus.to/idcee
Flickr: http://www.flickr.com/photos/idcee/collections/
5. Gig Kaplan
Entrepreneur and innovator. Age 43. born and based in Israel.
WIX – Co-Founder & CTO
•
•
Managed HR, R&D, System & Product for the 1st 4 years
•
•
•
•
•
Started coding at 12, My last line of code was 2003.
Focus - Product Road maps and specific products and HR architecture
CV
3 years army - Developer and Sys Admin
Co - Founded 6 software and internet start-ups, 1st one at 15
Involved in kick starting another 7 start-ups, 1 dance group, 1 nonprofit
Studied – Psychology, Philosophy, Yoga, Dance
8. Success is a team effort
People are your main asset
• Teams can have multiple leaders
• Good teams are skill balanced
• Keep teams small and personal
• Aggressive is good, Mean is bad
• Teams should allow individuality
9. Recruitment Process
Smart, Fun people that can Execute
•
•
•
•
•
Test people for real deliverables
Make the interview personal – do you like the person
Hire skills not knowledge
Go into details of a previous work experience
Check recommendations
10. Open culture is the key
•
•
•
•
•
•
•
Open doors if any
Goals and results are in the open
BI is open to all employees
Everyone can provide feedback
It is ok to fail, just don't be dumb about it
Problems are humored not hidden
People subscribe to reports
11. Indicators of a Healthy Culture
•
•
•
•
•
People recruit their friends
•
Do not give prizes
People meet after hours
People can be angry but are not mean
Few formal meetings
•
People meet and talk organically
People approach management
12. Human Architecture
•
•
•
Software architecture creates divides
•
Client, Server, System
Different roles creates divides
•
Product, Marketing, R & D, QA, Support
Work on breaking those divides
•
People should be able to influence out side of their
scope
•
Create opportunities for interaction
13. Product Management
is not a role it is skills
•
•
Passion, Focus, Eye for details
The 6 skills - no one has them all
•
•
•
•
•
•
Product marketing - Road map & Commercialization
Product analysis - Use cases
Product UX - Screens
Product packaging - Design, Text
Project management - Get it done, Organization
Technical knowhow - It should work :)
14. Developers are product people too
•
Good developers need to be engaged with the road map, users and the
creative process, otherwise they will kill the product
•
•
•
Become architects instead of coders
Developers must be given time to engage with the product
•
•
•
Develop technology instead of product
Brain storm, work on products, support users, meet users, access to bi
Developers must offload from PM
Technology is a product too
•
APIs, System architecture, DB, etc... are all products and should be
treated as such
15. QA & Support
•
•
•
Doubt your need for QA & Support
•
Use a good test driven methodology and
monitoring instead
Product & Dev should be engaged in both
Small & testable features should not be QA’d
but released
16. Good Practices
•
•
•
•
Product and R & D people should be in the same room
•
•
•
•
Feature assessment time should be slotted
All should be aware of road map, support issues, BI, etc...
All should be aware of everybody's work, and allowed to contribute
Go over the list of potential features and try to find the cheapest ways for
implementation - look for quick wins
Developers should be able to deploy there own features to be tested
Management should meet with team and not with pm to discuss road map
Get drunk together
17. Problem Indicators
• Long emails
• Long specs
• Bullshit ideological conflicts
• People talk in us and them
• Meetings
19. Early Stage Recipe
•
•
•
•
•
Get a great team
Get started - minimal feature set
Get to the market early, Get users
Launch
Constantly test & get feedback
•
•
•
•
Measure (logs, analytics, support calls,..)
Focus on the bottom line - conversion, usage, retention = $
Talk to users, see what they do with the product
Asses
20. Identifying the minimal features set
•
•
•
•
Define your basic assumptions
Always start with testing your assumption
Identify the minimal feature which would test this assumption
my favorite tool
•
Imagine yourself releasing without the feature
21. Getting to the market early
The don’ts
•
•
Ignore things your team can not do
Ignore good problems
•
•
•
•
Ignore scalability
Ignore architecture
Ignore future features
Ignore business model
22. Getting to the market early
The do’s
•
•
Focus on the differentiator
Keep design simple
•
•
•
•
•
Copy simple design from somewhere
Text should explain the value
Focus on the empty screen and the first steps
Provide a place for users to interact with you
Analytics and logs are a must
23. Launching your product
•
•
Minimal assumption on your users
•
•
•
Buy some advertising
Communicate with bloggers, forums, opinion
leaders
Multiple launch is easy - Try this
Provide feedback format
24. Measure Early
A/B Testing, Logs, Analytics & Monitoring
•
•
A company culture cornerstone
Feature testing methodology is key to acceleration
•
•
•
•
•
Makes sure you didn't break things
Reduces lengthy discussions
Reduces over design
Sometimes even acknowledges success
Allows everybody to release their features
25. User Feedback
•
•
•
•
•
More important then testing
Become the user - Use you own product
Talk to your users, they love it
Look at what they do
Provide feedback mechanism
•
•
Contacts, Chat, Forum, Wish list,...
Everybody should interact with users
26. Assessment - Failure
It is better to close early then a slow death
IF launch successful
Great
IF not
Did you get reaction from users
Improve
IF not
RETHINK
27. Assessment - Success
Understand why users use your product
•
•
This is your most important task
It can be:
•
•
•
•
•
a Specific feature
Combination
Packaging
Price Point
…
29. Product Deliverables
•
•
•
•
•
Must be simple - no one has attention
Lists - manage knowledge
Road maps - manage focus
Spec = Screens & Use Cases
Focus on the empty screen - 1st time user experience
30. Managing the Product
On Going dual effort
•
•
Optimizations are driven by lists
•
Bug fixes, feature improvement, user
requested, competitors, performance..
Leaps are driven by road maps
•
•
Good optimization effort can be a leap
Managed similarly to new product
31. Lists, Lists, Lists
Managing the feedback loop
goals
feature
status
owner
priority
source
wow
animations
p. ready
wow
rotation
R&D research
cash
billing brazil
research
CFO
operation
CDN monitor
tbd
CTO
users
Vision/ideas, User feedback, complaints, successes, Bi, logs,
monitoring, Operational needs (billing, system),
Competitors gap
32. Product road map
Facilitating discussion and alignment
• All the lists
• Inspirations
• Key assumptions
• Goals
• Resource allocation and shortages
• Critical action items
33. Managing Focus
• 3-6 month roadmaps
• half time work plans (1-3 months)
• 4 levels
• Can not fail
• Very important
• Opportunistic
• Maintenance/ongoing
34. Work plan
actual planning
resource
week 1
week 2
week 3
dev 1
C. F 1
C.F 1
C.F 1
dev 2
C.F 2
C.F 2
C.F 2
dev 3
List
vacation
List
dev 4
List
List
List
Dev 5
Maintenance
Maintenance
Maintenance
Know your real resources
How many do you really have
Allocate around the can not fail & maintenance
....
35. Commit to Plans
•
•
•
•
•
Once you have a plan commit and execute
Do not double guess
If derailed stop to reassess
•
Suicide mode doesn’t work
Drop the non critical
Do not drop the ongoing
36. Plan Early
• Use the Garbage time
• Post major release energy drop
• Stuff in Qa/Support/v1.1Phase
• Best time to plan
• Get the developers involved
37. Pit falls
•
•
•
•
•
Not enough time for effort estimation
Long tasks - not broken to smaller bits
Over Design
Developers methodology overshadowing
Not enough value in a work plan
39. Architecture is overrated
Use common sense instead
•
•
•
•
Assume you will rewrite your product at least twice
Keep it simple, keep it modular
Modeling before you know the domain rarely works
Patterns are overrated
40. Do not focus on scalability
Unless you have to :)
•
Scalability is a syndrome which happens to successful
companies
•
•
Succeed first - Focus on product and marketing
If you have to:
•
•
Cloud => CDN => Write/read asymmetric => Shard
SOA: Use carefully
41. Focus on manageability
Tests, Logs, Monitor, BI
•
The earlier you can intro testing, logs, bi & monitor them the
better
•
•
•
Use logs & Analytics from day 1
Start simple and evolve
Introduce a/b testing mechanism as early as possible
42. Don’t choose the stack
Choose the developers
•
It doesn’t matter
•
•
php/ruby/java/python/.net - they all suck :)
People matter
•
Choose the technology that your people know best or that
you have access to hands on expert
•
•
Create methodology and teach it to people
A great developer can work in any environment
•
A mediocre developer you can not afford
43. Clouds - are not 99.99
but your code has more errors
•
•
•
Delay creating a “system” as much as you can
For most product a cloud is the right choice
Do not own the machines - it costs more
44. Storage is cheap
abuse it
•
•
Make sure information is replicated and redundant
•
you will screw up
Do not bother to delete
•
•
Fragments disks
Very hard to recover from bugs
45. CDN is magic
abuse it
• Anything which can be delivered from a
CDN is scalable
• We CDN media, queries, page parts
• Use version variables instead of flushing
46. Data Bases are dumb
so keep it simple
• Offload to client if you have one
• If not, offload to app server
• Do not transact in the DB
• Use GUID instead of Id
• Duplicate data per index is not a sin
Time 60 seconds
- At our core, we offer solutions, packages and tools for creating fully customizable, feature rich, beautiful websites exactly the way the user wants it
- We provide a template but make everything easy to change so the end result is not identifiable as a template
- In order to just get this far, a company typically needs to spend thousands of dollars whereas we offer the tools and technology for less than $20/month
- To show you how easy, elegant and intuitive it is, we have a short video [play video]
Time 30 seconds
- If you think about the evolution of technology, the ability to contribute and participate in web development is progressing similarly to desktop publishing
- Used to need assets, skills, capital and expertise to create a document – today anyone from a CEO to an elementary school student can create a document in a few minutes
- Because of the network effect, platforms emerge – Word has become the de facto document creation technology, just like powerpoint is synonymous with creating a presentation
- Wix is positioned to become the platform for the web – once a user learns how to use Wix, they come back time and time again, they tell their friends, and they become strong advocates