Current state: I have prepared the design & features document. And developers will be joining team soon. Can you help me as how can I always keep a check on development and also have complete control over it?
P.S: I did OOP till 10 years back and I also have fair bit of idea of Python. Currently, I am developing a payment product for the lower income group in India and I aim to achieve a transaction time of less than 10s in days (years) to come.
I see two different threads here. One is regarding checking on development progress, the other is on product management. Iāll address them individually.
Product Management is a beefy topic, but in general, you should understand that a ādesign and featuresā document is outdated as soon as you create it. You should be optimizing your product backlog for short feedback cycles and delivering iterative value to the user. The longer between releases and feedback gathering, the more risk youāre building into your product.
For tracking developer progress, make sure you have your backlog in a state where individual user stories are ācompleteā and prioritized, and make sure everything is tracked in a tool like Trello, Jira, or Pivotal Tracker (disclosure: I work in the consulting arm of Pivotal Labs, and we use Tracker). If you build in a culture of frequent communication and updating of your backlog, measuring progress should not be an issue.
Thank you. Yes shipping is a priority and hence I have written on my desk the longer it takes to ship, higher is the possibility that it will not get shipped.
I am using Trello as a tracker tool and my conversation with the remote team is weekly. They are CS students in Univ of Waterloo (known them before they went to college).
Requirements have changed thrice in a month because we found efficient ways of doing the task during the pilot. Hence, the progress is slow. I donāt mind that because we want a min product that serves max adopters.
How is updating a backlog different than a tracker/ requirements document?
Check out the book The Lean Product Playbook by Dan Olsen, it is a great starting point and a quick read!
Make sure you pay your developer and that they are doing āwork for hireā. Otherwise, youāll not own the āproductā, they will.
Iāve never respected anything that comes for free and believe in it while hiring even an intern. I have always been paid and I make sure that payment is defacto.
I use a site called Bubble to quickly prototype my apps into a full working versions before spending money on ārealā development. You can have your team of coders remake it later with ārealā code to become more flexibleā¦ But this way you can have the product up and running VERY quickly to get proof of concept before spending a ton on developmentā¦
Bubble worked really good for me. Itās easy and fun. Thank you so much for the reference.
Iām a similarly non-coding founder. Weāre using a combination of trello and storiesonboard for product/project management, and itās fantastic.
In short, make a series of lists on trello: Inbox, To Do, Doing, and Done (we use more lists that are broken up to a higher resolution, do what suits you best).
Then make a project in storiesonboard. Set up all of the feature and technical cards as normal. Connect the trello and storiesonboard accounts, and push the cards from storiesonboard to trello in the order in which theyāre built. This way you can prioritize what is built first, and see everyoneās progress in real time.
Iāll leave learning how to use trello and storiesonboard for someone else to explain. Or you can just figure it out yourself, it isnāt that hard!
@Marco, Thank you. I am using Trello for the same reason. I donāt mind if someone can explain using storiesonboard & Trello further deeper.
Because Iām so generous, I made a short video showing how to create and link a storiesonboard project and trello board. Just make a storiesonboard account and you can link them up easily. Have fun!
Iām a product manager, and have taken the following approach with my own side project recently:
Weāre about 3 weeks into dev and Iām very pleased with the overall process. There is tons of visibility. I have a background in startups, and have been back in the corporate world for the past 3 years, so this is a breath of fresh air. Itās been super efficient.
Let me know if you have any other questions! Iād be happy to give additional details if itāll help.
Im still a senior in college for CS, but I can help out a little. One of the biggest problems there is you have to keep it an AGILE environment, and make the Software Requirements correctly. Make a ton of user stories of someone who is using your code. For example: user logs in, comments on video, likes the video, and later receives a notification that someone replied to him.
Make a ton of those, and a ton of Pictures representing what each screen will look like, as well as the logic for each use case.
As for keeping them in an AGILE mindset, have a weekly or bi-weekly meeting on what they did, and have them show that their features are working. Also get them in the habit of asking you questions. In fact, tell them the more you talk to them about things they arenāt sure of in the product the better, and the more they are fulfilling their job.
I think part of the reason that the manager loses control over the product is because either it is easier to do one way, or it is more logical. In java the GUI creator kind of sucks for example, and certain GUIās are hard to do, or the developer might not want or know how to do a very specific odd thing.
The more pictures of how the product works the better though honestly because it will not only help you flesh out your understanding of it and what you want, but also programmers inherently hate trying to be creative, and its always easier and less risky to program something that is shown on a picture, sketch or whatās on a whiteboard. If you have an artistic deficiency, Iām sure some artists would love 5-20 bucks to sketch a nicer looking arrangement of boxes.
Many aspects of agile development can be helpful and useful but many people take it too far. Make sure the agile dogma doesnāt kill the momentum of your developers.
Yes!
Iām 40ā¦been writing the codes professionally for about 20 years now, and come from the cowboy coding era before things were so specialized.
One of my actual strengths is to understand how design and coding fit together in a unique way, since I have a design background, and years of practical experience.
While I love the agile process to help identify tasks, it only goes so far as you break down the tasks.
If your technical manager just tends to leave big epics not broken down into their actual tasks, it can have a weird effect on tracking velocity and keeping on track.
But then there are tasks that take longer to write up, then just asking.
Right now weāre in the spot where we over-document, and I routinely get tasks that probably take 5 minutes to write up, where itās seriously like changing a hex color in a sass include or something trivialā¦
Since Iām the oldest, and only remote employee, itās kind of hard for me to really have a say in how that process is run, and itās just easier for me to adapt to whatever they come up with since Iām a little bit more used to thinking on my feet than some of the juniors, but they like to do weird things to cut Fridays short, and Iāve been suggesting āhey why donāt you design people, and you programming people just get together and talk about little tweaks for an hour or soā
Like whenever Iām out there and wrapping up a new feature, I make it a point to pull the designer aside and walk through what Iāve built with them, explain things in a way that they could design it more effectively (never about aesthetic, usually just little details at this point), and allow them to make a few adjustments so they feel like weāre working together on the product.
Thatās like the most difficult thing for them to do though, theyād rather have a 7 person team take a happiness survey than actually just talk shop and whiteboard because itās fun.
Thank you. We have already gone through two iterations of requirements and stopped at third because it made sense in shipping a product to understand our users than perfecting a plan.
Yes, I agree pictures make a lot of sense hence we have come up with wireframes. It decides the flow of the app and the developers can visualise the output before shipping it.
Even before developers have come on board, I am having weekly meetings with them to bring them at par with the way our customers are behaving in the pilot program.
I just came back to check this post. Dan Olsenās book The Product Playbook has been really helpful. One thing that has been consistent throughout the development is the user stories. It has really helped but we have not been recording it on any tracker. Weāve been managing it because we are a small team but we have begun discussions to take stories to Trello.
On the other side, we not only have our product with early users now but also paid customers! Woo hoo. Thank you so much.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.