The document discusses lessons learned from the development of Wuzzuf and Forasna, two of the top job sites in Egypt. It provides tips for agile product development, including focusing on optimizing daily goals and key performance indicators, reducing scope to move faster, emphasizing face-to-face collaboration over documentation, and prioritizing shipping minimal viable products over extensive features or specifications. The document advocates for an iterative development process focused on learning through small, frequent releases.

1. By Magdoub

2. Wuzzuf And Forasna
are the Top Job Sites in Egypt
Traffic > 3M / month

3. Wuzzuf And Forasna
are the Top Job Sites in Egypt
90% Market Domination

4. Wuzzuf
[Semi Waterfall Development]
Forasna
[Hardcore Agile Development]

5. Wuzzuf
[Semi Waterfall Development]
[Started 2010]
Forasna
[Hardcore Agile Development]
[Started 2015]

6. Wuzzuf
[Semi Waterfall Development]
[Started 2010]
I was Here
for 3 years

7. Forasna
[Hardcore Agile Development]
[Started 2015]
and...I was Here
for 2 years

8. Here’s My Story
Lessons Learned The Hard way

9. A Guideline For Making Decisions

10. A Guideline For Making Decisions
Specs Come Last

11. Many Small Steps
Myhical Big Launches

12. Forasna Daily Job Applications

13. Big Launch
Tv Spots
Radio Spots
Offline Aqc.
Online Ads Branding
Forasna Daily Job Applications

14. Forasna Daily Applications
Big Launch
Tv Spots
Radio Spots
Offline Aqc.
Online Ads Branding
Forasna Daily Job Applications

15. Forasna Daily Applications
The Honeymoon
is Over
Forasna Daily Job Applications

16. Today

17. Forasna Daily Job Applications

18. Big Launch
Forasna Daily Job Applications

19. Wuzzuf
Daily Job Applications since 2011

20. Forasna
11k Applications / day
Wuzzuf
Daily Job Applications since 2011

21. What Took Wuzzuf
7 Years to Achieve

22. What Took Wuzzuf
7 Years to Achieve
Forasna did it 1.5 years

23. OPTIMIZE FOR SHIPPING THE FASTEST
And the smallest, simplest thing that will get us
closer to our objective and help us learn what
works.

25. Just a simple signup
and Thank you

26. This Was the whole
Freaking Website!

27. This Was the whole
Freaking Website!
Just a signup Form

28. Version #2

29. Version #3

30. REDUCE THE SCOPE
In order to move faster and not spend time on
things that turn out not to be important.

31. Current Applicant
Tracking System

33. Current ATS Scope
List Applicants Scoring
In Page Screening
(popup)
Unlock / Shortlist /
Reject
Next & Previous
Profiles
Filters
Copy Job
Advanced
Handpicking
Mobile Friendly

34. Initial ATS Scope
List Applicants

35. First Version

36. BUILDING FEATURES
Daily Goals > Weekly > Monthly > Quarterly

37. BUILDING FEATURES
FOCUS ON OPTIMIZING
THE DAILY KPIs

38. Then Zoom Out Later

39. Daily Goals

40. Daily Goals Weekly Goals

41. Daily Goals Weekly Goals
Monthly Goals

42. Daily Goals Weekly Goals
Monthly Goals Quarterly Goals

43. OPTIMIZE FOR FACE TO FACE COLLABORATION
Two People talking on a whiteboard
much better than
Long Email Threads,
Complex Specs,
Meetings

44. Tools are built to help us not paralyze us

45. Using software to build software is often slower
than using whiteboards and Post-it notes.

46. Use the minimum number of software tools
to get the job done.

47. DESIGNERS WILL DESIGN,
DEVELOPERS WILL DEVELOP
DATA SCIENTISTS WILL …..
and you have to stop them..

48. They had best codebase in the world
They had best Design out there
Products Have Failed Even though..
They had solid proof Documentation
They had the best Data Scientists and
the Largest/most-complicated Dashboards

49. Nobody Cares

50. The “innovative” designs that were
“boundary pushing” were also practically
unusable in real life.

51. “building our own framework”
Because we won’t be using be using 70%
of the components in Bootstrap added
unneeded Complexity and slowed us down
by 6 months

52. SHIP THE FREAKING PRODUCT!

53. SHORT CLEAR BROKEN-DOWN SPECS
Short Specs but to the point

54. “Writing down decisions is essential”
Only when one writes do the gaps appear and the
inconsistencies protrude...

55. The act of writing turns out to require
hundreds of mini-decision, and it is the
existence of these that distinguishes clear,
exact policies from fuzzy ones.
F. Brooks - Mythical Man Month

56. What Problem Are We Solving and Why?
Provide Context
Add links to
research or data
points

57. How we will Measure Success?
Provide Vision

58. How we will Measure Success?
Provide Vision
Julie Zhuo
Product design VP @ Facebook.

59. How we will Measure Success?
Provide Vision
“We’re launching feature X because we think
it will do [fill in the blank here]. We’ll invest on
making it as good as we can for N months. If
after that, less than Y% of people are using it
daily, we’ll remove feature X”

60. Adding Scope
Limitations are good
It stops over Engineering (generalizing everything)

61. Visual Specs are Much Easier

62. Visual Specs are Much Easier

63. Visual Specs are Much Easier

64. What are we going to do with the old Data
[Migrations]
What QA Scenarios Needed?
Questions To always Ask
What Metrics do I need to Track the Feature?
Should we Notify any of the teams beforehand?

65. Thanks
Top References
*From Intercom’s: Scaling a product Team
*Rework by 37 signals
*Getting Real by 37 signals
*Spotify’s: How we do work